Jump to content

MaxDZ8

Members
  • Posts

    17
  • Joined

  • Last visited

Recent Profile Visitors

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

MaxDZ8's Achievements

Member

Member (2/4)

0

Reputation

  1. Sure. As start, open vivado and in the language templates you can search for xadc. You will find a snippet for verilog instantiation. I do NOT claim to understand it right away. See UG480; it includes a more elaborated example. Uhm, are you sure your platform project compiled correctly? How did you get there?
  2. Thank you Zygot, honestly I couldn't believe my findings I hoped really there could be another way (but I knew since start your suggestion made sense!). Yes, I agree. I'm trying various things for the time being as I approach a methodology which gives trustful results. It's taking me ages and I often forget things in the evenings but I'll be getting there... at some point ? Nonetheless, I already bought a Kria. I am confident its "reasonable" level of performance will satisfy my needs.
  3. I can't help with the USB issue but I sure can help with this. The whole Vivado/Vitis "project" thing is a utter nonsense. I try to convince myself it makes sense on a different mentality but no, "projects" in Vivado are a joke! Vitis is sorta better but I wouldn't say it qualifies as "decent". Don't even try importing anything which is more than a version old, this works only sometimes and the malfunctions can be non-obvious to say the least! Vitis comes with its own examples. When you create your application project, select "TCP/IP echo client" as test. Again, you'll need to fiddle with it. I have obtained my client from the example - it works on the Arty and I expect it'll work on the Cora since the ethernet subsystem very similar. You don't need to configure anything on Vivado to use TCP: everything you need is already in hardware on the Zynq, just importing the PS7 IP (and the related circuitry) and you'll be set. Is it clear to you how the Vivado -> Vitis interfacing goes?
  4. What are your concerns? As far as I can tell the only difference between the Z10 and the Z20 in the SoC and both use the same architecture and technology, everything else is the same. If your project fits and passes timing on the Z10 fabric it will work. If you use a single thread the CPU code will be the same. OFC it is not a complete 100% guarantee. Those things don't exist in reality. In general, you don't need to really buy to have Vivado (or Vitis HLS) run their magic. If they tell you everything is fine, odds are they are right (except when they're cathastrophically wrong, but it's kinda rare).
  5. Hello Delmas, I would ask: what have you tried? But really, help us help you. What issues are you having? Does the host app compile? Do you get link errors? Something involving makefiles? As far as I can tell, Vitis examples don't even know what boards they'll be running on and they add a lot of useless cruft such as the I2C handshake which shouldn't be there (and it isn't compiled as it's guarded by #ifdefs). Do you get to at least complete PHY initialization?
  6. I think we have managed to find a common point, thank you. I don't know how I will do in other chapters of this book but for the time being, I would be happy enough with putting a stop on this issue. Pulling in the XADC measurement took more effort in finding the documentation than the work itself but the process has been straightforward. The first batch of runs I made passively cooled. I tried: 6 stages, no buffers, 100 Mhz - LUT29% FF30%, Vivado estimations 2.415W, 52.9C. Highest tmax reported 54.7C after about 4 hours. 6 stages, full buffer, 200 Mhz - LUT 29% FF39, Vivado estimations 3.443W, 64.7C. Highest tmax reported 68.2C (this has been run by the day so the temperatures are not completely comparable, it was about 2C warmer). OFC it makes no sense to run this thing... 12 stages, no buffers, 100Mhz - LUT52% FF50%, Vivado estimations 3.328W, 63.4C. Highest tmax reported 70.7C after about 4 hours. I must admit I am a very surprised by the temperatures, there can be up to 30 degrees between heatsink and core o_o ! This really puts way more emphasis on the industrial temperature range, I'll need to reconsider my hardware choices but considering other news today this is might be good thing. Nonetheless, after this batch of runs, I have figured it was best to turn on the fan and went to another few tries. 12 stages, full buffer, 100 Mhz - LUT52% FF68%, Vivado estimations 3.188W, 61.8C. I let this run almost 8 hours and the highest tmax reported was 49.7C. 12 stages, full buffer, DSP, 100Mhz - LUT50%, FF67%, Vivado estimations 3.221M, 62.1C. After over 10 hours the highest temperature is 53.32C All those run off USB3. With those I think we explored pretty finely this power range. The goal is to run this at 12 stages and 200 Mhz. The design is simple enough as the resource usage is again LUT52% FF68% (I mean, the tool has no trouble at all at PAR nor timing, there are a couple bits replicated here and there but that's it). As before, running 12 stages at 200 Mhz causes an instant hang. On USB I could understand but the same thing happens on +12. Let's see if I can manage to convey my disappointment. The ArtyZ20 documentation reads: Certainly driving peripheral is a different matter. Yet I think this wording is not sensible. It seems to me USB power can max board capabilities. Granted, the USB host is key but the bottom line is reading this I understand the jack will provide more juice. I do not expect to run arbitrary bitstreams but I do expect there is a class of reasonable bitstreams and I would expect something being 99% pure compute to rank in this range. This is particularly important as a variant Z20 is also sold as PYNQ. I assume the PYNQ won't (by usual designs) run at higher performance than the base clock and so I assume it will be stable. As much as I appreciate the benefits of having a higher voltage supply I think suggesting the jack can provide more power is a mistake. This doesn't seem to be the case. The seems to be no benefit in using the jack in my case. The board seems to me more limited than the documentation seems to suggest. I'm tempted to hook to I2C and check TPS settings but I suspect it'll be useless. Perhaps it's just time to accept this is the limit of the board and that's it. It seems my vendor managed to find a couple boards at the bottom of the barrel so perhaps I will be lucky and get some other hardware by the end of the month.
  7. Hello Zygot, thank you again for the input. I don't know what to say more than that, your help is invaluable. I need some more time to digest all this content. I feel the need clarify a key thing. There has been a time I when I followed and even advocated for best practices. In my spare time I cannot quite stick to it anymore - just today I got assigned to yet another year-long project which would require a whole team and I'll need to complete in in a few months! I agree with you about power delivery; above I tried to make sense of whatever the power delivery was woefully unreasonable but certainly I am not in the position to assess the quality of those rails, whatever maybe grounds gets to bounce too much, or maybe it's about the dynamic adjustments or an interaction in switching activity. That's what I get, unfortunately. It would be a total let down. As for source control, I would say Vivado project mode is whoefully inadeguate; I've been fighting it for months by now. Yes, it can be put in source control but it's super very noisy, especially as IP is involved. I honestly have no clue why Xilinx even proposes it as a starting point, at the end of the day I use Vivado just for the device view! The project is in a repository nonetheless, perhaps in the next few days I'll play fiddle with the previous versions as well, for the time being I will re-calibrate my understanding of device temperatures, as this seems to be a solid step forward.
  8. ??? I'm not sure I understand those things. Probably because I have a different mindset. First, minor thing: XADC user guide is UG480 (four hundred 80). For the purpose of future readers, I think it is a good idea to document the progress what changed since last time? It turns in the refactor to time 200Mhz I flipped a bit in the 'start work' functionality which would cause the device to almost never transition back to ready state. By itself, this caused the CPU code stall. I took the occasion to rework a bit the thing to be more robust so I could at least run something. The data I have acquired today I can't bother pulling the old, known-to-work design for testing. It was a 6-stage pipeline clocked at 100Mhz with a Vivado estimation of 2118mW (that's accurate because I have it on note). I ran it four hours passively w/o heatsink and it ended clearly above ambient temperature. I wouldn call it even lukewarm. By now, I have performed a couple extra runs (I have added a small heatsink to the SoC). 6 stages, 100Mhz, I forgot to pick the estimate but if memory serves it was about 2.3W. I left it running the whole night and it was definitely warm. A scanned a bit with an IR thermometer and measured 36C at the SoC and 33C at the TPS65400. 12 stages, 100Mhz. Vivado estimates 3.313W and 63.2C temperature. After about an hour running I measured 45C at the SoC and 39C at the TPS. I would believe +20C between heatsink and core to be enough of a diff, at that point the core would be at 65C. It starts being uncomfortable but I think there's still more thermal headroom... except... I have measured 58C on the caps between the SoC and LD4. I suspect the thermomether might have been fooled by the shiny surfaces, yet the whole board is definitely lukewarm. The situation seems to be worse on the back side. I would classify both cases as "rock stable". Additional considerations On digikey, TPS65400 is 4.20668€/250 pieces. The arty z7-20 is less than 180 EUR. Considering the design costs, all the other components and assembly I think it is reasonable to think Digilent dimensioned the power supply for the -20 variant and shared the design with z7-10. The reference seems a bit conservative with the currents. TPS65400 datasheet notes buck3 and buck4 can output 2A on first page. Junction is a hefty 150C. The Arty Z7-20 schematic notes vcc1v5 and vcc1v8 both at 1.8A which sounds good to me. It seems vcc1v0 is a bit underpowered at 2.6A while vcc3v3 seems to be a lot lower at 1.6A but all things considered I doubt it really even needs that much. Some simple and most likely wrong numbers, adding the wattage of each of those rails gives me 13.8W which would be 2.76 amps from at 5V. Not impossible but definitely more comfortable on 12V. Notably, the power adapter for PYNQ Z1, which is almost the same as Z7-20 pours out 3 amps! I have no clue how a chip such as 7Z020 can possibly dissipate even just the 13 watts from the TPS but I guess there should be some room. Random thinking Which clock should I be feeding to my MCMM/PLL? Is there any chance feeding it the AXI clock can give issues? I honestly don't like how it routes, perhaps there is a better candidate? I need to do more tests.
  9. Thank you for the pointers, I have been interested in using XADC for long time so I will take this chance to read UG780. It is my understanding bare metal apps run on core 0. I will try rebuilding the Vitis project to run on core 1. I hoped the issue would be about main PSU dynamic response but if both Z7-10 and Z7-20 use TPS65400, then either the -10 variant is hugely overspec'd or the -20 is underpowered. The -20 is thee times bigger! Nonetheless, I have been trying to run some... something very similar to the old device from weeks ago (it has a few thousand extra flip flops but that's it). Well, it seems I can't get anything really to run on it anymore! My plan was to move this on A100 but with the ridiculous situation with silicon now, odds are I'll need to wait at least another 2 months! ?
  10. Erm, I understand those things up to a certain point. I have dumped "fpga DRU" in duckduckgo and found those two links across the garbage. For "XADC in PL logic using DRU", I have found a little more interesting content here and there but I don't quite connect the dots. What does that even mean? Anyway, I guess it is a good idea to take a step back and start from easier things first I've left out some important information. The Arty Z7-20 has a magical green led LD12, labeled "done" it turns on after FPGA bitstream has been uploaded. This is supposed to be on basically all the time. What I observe: LD12 turns off when compute starts. I'm not deep enough in the tech to understand how this LED is driven but I'm inclined to believe bitstreams must be truly garbled to interfere with it. Another interesting LED is LD13 (RED) described in the reference manual as "on when all the supply rails reach their nominal voltage". This also goes off. The process overall is as follows: Power on +12V rail through jack. Red LD12 on. Green LD8 on. Run tera term. Connected to COM. Run Vitis. I launch the project as Assistant tab > Debug > context-menu > Debug> Single Application Debug In maybe a second fpga is programmed, LD12 on. Debugger on first line of program. Red LD5 on. (Not considered relevant: I must run the orchestrator here, it's the program cooking the data for easy consumption) Canonical ethernet traffic is observed Debugger hits breakpoint at parameter setup. Continue. Debugger hits breakpoint at 'start compute'. Continue. LD12 blinks off. This behaviour is compatible with running from USB3. I think at this point I'm not sure of how adding UARTs or monitors in either PL or hardened SoC features can help me. There's still the possibility the PSU might fail in adjusting fast enough. I'm considering taking down the thing with me at work when I can use the scope to monitor 12v voltage in but that's pretty much it.
  11. Thank you Zygot, I have difficulty boiling down the suggestions to a concrete course of action. For the time being, I notice this: That's a scary possibility! My design pours out a few monitor signals which are fetched to a not-quite-PWM. If memory serves it should be pulsing at about 200khz. It all goes through FPGA fabric. Indeed, the system does poll HW through AXI quite frequently. Assuming no bugs it should happen a few times a millisecond but I am inclined to look elsewhere as in my debug runs I am stepping through manually and it still hangs at dispatch, it never even gets to execute the following instruction, let alone the polling. What can I be looking for? Last few notes: I was not going to add caps at random to something featuring sequencing. I meant to add them straight out of the power supply as I know this supply can't boot 3 rPis reliably and I'm pretty sure the hardware I have sythetized is more power hungry than 1 rPi. I know from previous experimentns the caps can smooth out the dynamic loads enough for it to make it through but that's the best I can reason about. No, I don't have a scope at home. I don't know where to hook the probes, I haven't even looked it up because I'm not skilled enough at soldering to bring out those traces. From the Arty7-20 reference manual it seems for FPGA 1V is 2.1A typical, while 3.3 is about 1.5A. I am a bit surprised to find out those are alrady in the right range to give me issues. I understand using the integrated device could help assuming the issue is related to ARM core communication?
  12. Hello, I hope you will be enjoying your vacations if you have been given some. For me this has meant finally being able to work on my spare-time experiment and finally reach closure on my upgraded design. Let me describe the process. The ArtyZ7-20 is just the initial prototyping. I'm going to move to real production FPGA boards ASAP (probably in August) but for the time being I'd just want to go ahead with the Arty. The system is systemverilog RTL and barebone C++. The initial design was 100Mhz and 6-stage pipe. Vivado estimated about 2.2W power. I suspect it was much lower than that. I ran it over USB2. Let me be clear my mainboard has a fairly beefy usb2 going beyond usual specification. I later went ahead with a 12-stage pipeline. I was unable to run it on USB2, but it runs rock stable on USB3. In the last few weeks I've upgraded it to 200Mhz. Vivado now estimates 5.5W. I never expected this to be able to run on USB3 power (I haven't tried, but I doubt my USB3 can deliver 1A) so I've hooked the ARTY through its power jack to a industrial supply (details, if needed, in a later message) The board gives up. If I leave the board free-running, it hangs almost instantly. Here's how it goes by stepping it in the debugger: Booting ok, DHCP fails (ok) and fixed ip is estabilished. Server correctly found, input requested and correctly received. Input feed to PL PL start As soon as I pass beyond the {4} breakpoint, the card hangs. The debugger will never hit the next breakpoint. I can tell the thing is more relevant than just software because my PL turns on red LD5 when idle. It would turn on green and eventually blue plus animate LD0-3. This never happens. I was thinking about hooking a bunch of capacitors to the supply and see if it improves but I guess there might be other issues to consider as well. Do you have any suggestion?
  13. Hi! I appreciate condensing the introductory posts into a sticky thread and I figured I can write some as well. When someone asks me what I do I answer "software, for the people". It is a broad simplification. I've historically been on the edge of computing for a while and I got in GPU computing really early. FPGAs have always been a curiosity. I managed to get an Arty Z7 only recently and I occasionally play with it when my day job "bubbles". So far, I have been enjoying it greatly as "I can haz my pipelines back"! I have signed to this forum as I plan to ask more info on this board after some more extensive search.
×
×
  • Create New...