Jump to content
  • 1

Vivado - How to reflash HDL code quickly


ho0pla

Question

Hi everyone

I just got my Nexys 4 DDR and I'm trying to get familiarized with XDC files and writing some basic HDL projects.

I know how to generate a .bit file and program my FPGA, but I was wondering if there is a quicker way than Synthesizing, Implementing, and then Generating.
It takes like 5-6 minutes right now. I'm making little changes to my Verilog source files very often so this re-programming time seems absurd.

If I JUST make a change to my .v file, what is the quickest way to reprogram my device?

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

I know it sounds stupid,. But sorry, that is how long it takes. There is no short cut.

For example, global optimization may cause logic to get 'thrown away', and that would need to get inserted back into the design somehow.

Link to comment
Share on other sites

Hi,

as an introductory motivational speech: You just ran into one of many snags that ultimately explain why the FPGA guys tend to earn more than Python programmers :)
If you're interested in FPGA, you may take it as an excuse to dig into the tools manuals for optimization options ("synthesis and P&R strategy"). Most likely it won't make a big difference, but you may pick up something randomly along the way (just getting stuck in my own projects isn't the most efficient way to learn).

Now building a dummy design on Artix 35 (a single UART Rx-to-Tx combinational connection) takes 1:55 min for me, between reset_project and final bitstream. OK, this PC was custom-built for FPGA design (6-core i7 overclocked to 4.5G, quad-channel RAM and M2 SSD). On Windoze, try to turn Windows defender off, this may actually make a bigger difference. If overclocking, 1..2 active core clock rate matters most since they will be rarely if ever fully loaded by Vivado.

I suspect you have some mistakes in your design that make the job unnecessarily difficult for the tools. See this post:  Most of the topics are a bit advanced but "missing constraints on off-chip IOs" is a very common mistake / omission: The job gets much harder for the tool, and it needs to iterate.

set_param general.maxThreads 8

may help for a larger design but it made no difference for the simple test.

Try to delete everything but a single wire between two pins and check, how long it takes.

Link to comment
Share on other sites

12 hours ago, hamster said:

I know it sounds stupid,. But sorry, that is how long it takes. There is no short cut.

For example, global optimization may cause logic to get 'thrown away', and that would need to get inserted back into the design somehow.

Thats really surprising. I'm used Altera's tools for the last few years for school and re-flashing code took maybe 30 seconds.
Perhaps we had a special kind of setup.

Link to comment
Share on other sites

2 hours ago, xc6lx45 said:

Hi,

as an introductory motivational speech: You just ran into one of many snags that ultimately explain why the FPGA guys tend to earn more than Python programmers :)
If you're interested in FPGA, you may take it as an excuse to dig into the tools manuals for optimization options ("synthesis and P&R strategy"). Most likely it won't make a big difference, but you may pick up something randomly along the way (just getting stuck in my own projects isn't the most efficient way to learn).

Now building a dummy design on Artix 35 (a single UART Rx-to-Tx combinational connection) takes 1:55 min for me, between reset_project and final bitstream. OK, this PC was custom-built for FPGA design (6-core i7 overclocked to 4.5G, quad-channel RAM and M2 SSD). On Windoze, try to turn Windows defender off, this may actually make a bigger difference. If overclocking, 1..2 active core clock rate matters most since they will be rarely if ever fully loaded by Vivado.

I suspect you have some mistakes in your design that make the job unnecessarily difficult for the tools. See this post:  Most of the topics are a bit advanced but "missing constraints on off-chip IOs" is a very common mistake / omission: The job gets much harder for the tool, and it needs to iterate.

set_param general.maxThreads 8

may help for a larger design but it made no difference for the simple test.

Try to delete everything but a single wire between two pins and check, how long it takes.

Thanks for the info!!

I am very interested in FPGAs as I want to make my living using them and related tools, so I will most definitely take a deeper look at stuff like this in the next few months. :)

Link to comment
Share on other sites

good ?

One more hint: A simulator and the warnings window / timing reports from Vivado are the key tools.

If you start with Verilog (as opposed to VHDL), iverilog plus GTKWave can be extremely useful to debug the logic (cursor-up / return / alt-tab / ctrl-R takes me about 1 second. This is the immediate feedback you were looking for). There's nothing special about it, it's just mean and lean and works.

Implementing the design in Vivado up to bitstream is important to keep in touch with reality - HDLs were originally implemented for simulation, not synthesis, and a great deal of online information is just misleading for FPGA, telling things that aren't implementable. You won't get rid of many warnings, but understand every single one. Vivado is trying to tell you something you need to at least understand as a concept. Consider it an automated private lesson. The compiler is your friend. All it takes is a lot (and I mean a lot) of time.

Hardware debugging is actually fairly limited - essentially it tells me "simulate some more and re-read the warnings..."

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...