• Content Count

  • Joined

  • Last visited

About Paul_kimelman

  • Rank
    Frequent Visitor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks, I will look at that. As it turned out, the person had Vivado installed and did not even know it, so I slipped by this time. But, I will look at this OpenArty project before this comes up next time.
  2. I have given Arty boards to some people, and now I need to update the SPI ROM. Is there something smaller than the fully Vivado and its HW manager for doing this? I would assume something that just connects to the USB and programs it the same way (with a bin file). Sorry if this has been covered before, but I cannot find it in the forums nor in the manual.
  3. I should have been clearer: your level shifter board is not feasible because you made the DIR lines only available by switch and not by FPGA pin. That is really sad because if the FPGA could control direction then this would work fine. Do you know if anyone has a PMOD which already does this? Else I will have to spin a small board myself I guess.
  4. Wow, that is really a shame. I realized I could not access the balls, but normally you can just use the decoupling caps that connect to the balls. I was afraid of this that he used a power plane. Sigh. The level shifter is not feasible since the pin involved is bi-directional and so a level shifter is not feasible (for any kind of speed anyway). In theory I could treat as unidirectional and wire OR on the 1.8V side, but that may be too messy. I will have to consider this. Thanks. I do think you guys need to consider that 1.8V is becoming far more common. A spin of this board could have a post to feed one or both of the general banks, using a trace instead of the 3.3V plane (or using a split V plane). Given the decap sizes, I suspect that you are not carrying that much current, although bank 15 seems to be assuming a lot more noise given the extra decap C. Thanks, Paul
  5. Hi Jon. Any feedback from the layout guy? Thanks, Paul
  6. I want to rework some Arty boards so bank 14 is 1.8V vs. 3.3V. I had planned a simple tying of a patch wire from C71 high side (1.8V) to C21 (or one of the others in C21 to C29 decap set). That is easy. But, I cannot see where the trace is that feeds C21 to C29 and so the bank 14 balls. There is no trace showing on bottom (where the caps are) nor on top (where there are what I assume are plated through-holes (covered in white paint, so hard to tell)). I am unsure if this means a 3.3V plane/layer on board but if so, I do not see where it is going. It seems unlikely you would use blind/buried via on such a simple board, so I am mystified. Can someone from Digilent explain the routing for that one power net so I can see if a rework is possible. I had assumed it would just be a trace cut, but I cannot see which trace that would be if so. Thanks, Paul P.S. Seems pretty crazy to still not have 1.8V as a bank option given how common 1.8V has become.
  7. interesting. One obvious use would be to have one running a Pmod display, so the other(s) simply write into a frame buffer and then trigger an interrupt into it to update. I suppose I could also add a serial port mux/demux, so you can use an input char to select different MCUs to speak with. That could be interesting. I would need to buffer the output, but that is OK. I need to think about that, as it could add an interesting use model for certain types of tests. Thanks, Paul
  8. This is an interesting point. I don't need the extra horsepower since my focus is on the digital IP (which is of course being developed for use in Si chips), but it is an interesting point. Of course multi-core is kind of a hassle to program. I have not bothered connecting the debug up by the way; I suppose i ought to, but I have only been running test code on the MB that stimulates the HW. I might want to if I connect up some of the Pmod devices I got (for fun).
  9. Hi Zygote. I found that when I used MicroblazeMCS, I was able to do so in a very normal flow. It creates what ISE called a "core" which I get to instantiate into my top. This is unlike the craziness of the designer which makes it very hard to integrate into the system since it will not do external properly and it will not accept an incomplete system - they want you to import your IP as a package or set of. You have to match naming and ports and their whole packager is a disaster (I found it would not forget a port I had deleted nor a param I had removed, and its auto association only seems to work for AXI names if you follow their exact names - gets clock wrong, etc. But, the MBlazeMCS was fine - I did not need more than it supplies and I wrote a simple IO bus to APB bridge (all of 8 lines). On your point about modifying the wrapper (or using your own), then you have to never make a change to the "designed" system. The MCS model at least allows you to update it (e.g. change memory, add more peripherals, etc) with no issues (other than SDK not updating the memory size - has to be done manually). You can also add other peripherals as cores like normal.
  10. I work in software development, and in a lot of my contracts my job was to clean up after those "best" lazy engineers... Real best engineers don't know the meaning of word "lazy" because they know the price of error could be very high. Currently I work for one of major automakers building software for some of its' shop floor robots, and here mistake can cost lives and injuries of people, not to mention destroyed hardware. So I'd better take my time than go to jail... Yes, and I have worked medical and auto safety system - both HW and SW. I build IP for chips now and that would be $M down the tubes if bugs in it. I have spent plenty of time cleaning up after SW engineers more often than HW. This is not because they are lazy, but because they are sloppy. You can study the manuals for a year and it will not fix sloppiness, disorder, etc. In design engineering, you have to be better because it is going into Si. But, that does not stop you being "lazy" in the sense of not wanting to waste time on having to read more documents because the tools vendors and others have done a sloppy job or because people cannot organize their info into tables and so on. You can install them side-by-side, without deleting old version. At least that's the way it works in Windows. It is too big. I am running on an SSD and Vivado is 25GB on disk, and that is with support for various things turned off. I like Artix-7 too, but it's a bit of an overkill for good portion of my projects, so I can't wait to get my hands on their brand new Spartan-7 chips. On the other side of the spectrum, I would like to get Arty-Z7 with Zynq, as one of my project involves computer vision and for that I need a lot more horsepower out of MCU than softcore (or even several of them on a single chip) can provide. I am hoping that Spartan7 is a solid device and not the disaster that is Spartan6. But, truthfully, I am only using these for IP pre-Si validation, so I don't care much. I can see you would want a high end Cortex-A processor if its is your whole app - a lot of setup work though. I have been doing some experiments in vision with CNN approaches for classification, but that is all about vectors and data plane - the processor is not used much. Anyway, looks interesting with the Arty Zynq board.
  11. When it comes to pin naming, I've seen it both ways approximately equally often, so I wouldn't call either one "normal". Which is why I always read datasheets to find out the right way, and don't just hope that I can guess it right. That would be very strange since it is a standard (EIA) and they say exactly how you should name. Not sure where you have seen that. Among ST, NXP, TI, etc I have only seen people follow the standard and name it correctly. There is more into linker script than memory. And the reason they can pick it up once is because that's the only time they can be sure they won't overwrite user edits.If I would be them, I'd ask user if he modified that script offering to overwrite it, but existing solution is quite sensible from "the principle of least surprise" standpoint. This is not a makefile and batch tools. This is a GUI based on Eclipse. Most simply feed the memory regions of the chip into the linker file so the user can edit to their hearts content. I also find your argument amusing since they have no problem changing files throughout the whole rest of the thing regardless. In fact, that is kind of their point with the dialog that pops up. As for active-high reset - I don't know if that's the case with ASICs, but for FPGA IPs it's extremely rare to use any active-low signals internally. As a matter of fact, I can only recall one IP that has active-low input - and coincidentally this is IP to manage reset signals throughout the system. Actually, FPGAs do not like internal resets at all as a matter of policy. But, PROGRAM_B is the master reset of the chip and of course it is active Low. Most logic uses active low: always @ (posedge CLK or negedge RSTn) ... This is the standard for a lot of obvious reasons including that the net will be Low during POR when the V is coming up. So, it is safer and smarter. Actually it's the opposite - it's amateurs are people who want results "right here and right now". Real professionals know that they gotta read documentation before doing anything with component/part/library they've never worked before. And you've just kinda proved the point - if you would've spent 15 minutes skimming through datasheet, you wouldn't end up wasting so much time chasing ghosts. In my opinion, lazy people do not deserve to call themselves professional engineers. Sorry, but that is BS. If I follow an example or tutorial, then I do not have to read through pages of user guides (there is no data sheet sadly) that do not have the information in nice tables but have drawings and lots of words. I use components all the time, and all such info would be in a table in one page. I would have saved myself lots of time if the .xdc file had the comment saying which direction, especially as (a) non-standard naming for a chip, (b) Diligent is not consistent between Basys, Nexus, Arty, etc), and (c) it is normal to put this in the signal list (a form of table) since you know it will be seen since you have to uncomment the ones you need. Most professionals are "lazy" in that they do not want to spend 3 hours reading all of these documents - don't know where you work. I have been in this industry for more than 30 years, and the best engineers are always "lazy" and very very effective. BTW - new version of Vivado (2017.1) has been released just today. You might want to get it installed to see if it more stable for you or not. Yes, I saw that. But, given Xilinx's track record, I will wait and see what other people find. They tend to release new tools and then days later they start updating it to fix all of the things they did not test. I cannot afford to be down. I did finish my project, but still it could take them weeks to resolve issues. I ordered a 2nd Arty board since I had to give my 1st one to someone to take on their travels. I am going to try it for some other IP I am working on. I am so far happy with the Artix7 - seems as reliable as the old Spartan3 series, unlike the disastrous Spartan6.
  12. Agreed. But, this kind of thing is a time waster. I had the MBlaze MCS system builtin in under 30 minutes and then wasted 30 trying to see why the MBlaze was not running (reset) and then another 20 trying to see why no UART output (of course I blamed teraterm at 1st). I suspect many people get trapped by this, so it is a reason to make it better - and that is not hard. At Luminary Micro (2007) we had a rule that a high school student had to be able to have a board and the tools running in under 10 minutes and able to make a change to the source and running in under 20 more. The tutorials were based on watching the students to see where they went wrong and then making it clearer. This was not for boards for students but for professionals. Most professionals have no patience and want to be getting work done quickly. I can never get my wasted 5 hours back from discovering how many bugs Vivado Designer and some of the IPs have.
  13. Sorry, I've lost you here. You are going to use UART but you don't know if you need to know a pinout of this port? The picture in the reference shows directions. I mean that you do not know that the board has the pin names backwards. The UART standard is to refer to TX and RX from one's own position not from the other side. So, you do not know that the xdc file is backwards unless you find that drawing and realize the arrows are inverted from normal. Really? Every MCU linker I've ever seen defines MCU's memory layout in a linker script, begardless of platform. I worked with ARM Cortex M0,M0+, M3, M4 and M7, and all of them has the same ldscript file, and all environments have it in one way or another. That's where you typically go to make changes if your board have some external memory attached to MCU (via SMC, Q-SPI or some other way, but first two are most often). I can't really fault Xilinx here - Vivado is a professional tool, which implies that it's users have of some knowledge of the basics. Actually, the common approach when they know the MCU and Board (e.g. Keil, IAR, NXP MCUXpresso, Greenhills, etc -- all professional tools) is to decouple the knowledge of the board/MCU from the linker script assignments. I would expect to define section allocations but not define the total memory in a user controlled script since that makes it non-portable. If you define the memory regions outside, then you can use it on any MCU that has enough memory since it will just place it for you. If they are picking up new info on the system, I would expect that warning to indicate that they pick up everything ***except*** the memory info which they only pick up exactly once apparently. It is common sense in my view. I am not sure you argument: anything that makes it harder to use or more likely to go wrong is worth looking at how to make it better and less likely to go wrong. Your argument on reset is equally flawed. I agree that most of the world uses active low reset, so why doesn't the MBlaze use active low reset like everyone else? If they choose not to, then call it out in the instantiation template. I built professional tools for years and I was able to make it as easy to pick up and use as possible.