04-02-2013 09:33 PM
The ChipScope in ISE or Debugger in Vivado has poor scalability and flexibility in design methodology.
Do you think my way is better? See snapshot below~~
04-04-2013 08:29 AM
> The ChipScope in ISE or Debugger in Vivado has poor scalability and flexibility in design methodology.
Your assertion that the ChipScope cores have poor scalability and flexibility is not correct. A designer can insert ILA cores into a design with any width and any depth providing that the resources are available. This is in contrast to your proposal of cores with fixed interfaces and a maximum of 64 bits. A designer that needed more than 64 bits would not be able to debug in your proposal, but would with the current ChipScope.
In addition to addition costs and restrictions that would be imposed with hard blocks and dedicated routing, added a 128 Mbyte (8bit x 128 Mbit) memory in the device would be extremely cost prohibitive as it is more memory than is available in a FPGA memory on the market today.
04-05-2013 08:45 PM
For the term "scalability" & "flexibility", I didn't mean the configuration of bit-width & -depth. I refer to the design flow.
Everytime when you have to re-config the prober, you have to re-go the whole implementation flow, it's really a wast-of-time and sometimes it meets timing closure problem. And in some case, it might cost large porttion of BRAM and SLICE. For complex trigger conditions, the capture/trigger logic might see timing closure issue too.
If the capture pool and capture controller can be made hard core (just like built-in FIFO, with hard storage pool and controlling logic), this can solves all of potential problems above.
And for each debugger_prober, the 64-bit width is just a proposal, you can set this much wider, and why not? And maybe each clock region can have 12 debugger_prober access port, since one clock region have 12 BUFG/BUFH access port.
Finally, the silicon for this is not expensive. As I stated, you just think of this as a much bigger built-in FIFO, they are substatially the same! And just remember, the routing resource in FPGA is where your 99% money spend on.
04-09-2013 07:11 AM
I see most of the people are understanding "scalability" & "flexibility" as bit-width & bit-depth.
Actually, the "scalability" & "flexibility" has other dimensions to be measured. De-coupling the debug from design is a very important dimension. Keeping timing closure independent of debug core is another. Having dedicated routing resource for debug core is the 3rd one. The list might go on.
04-09-2013 07:55 AM
> Actually, the "scalability" & "flexibility" has other dimensions to be measured
Redefining common industry terms is not productive and leads to confusion. What you describe falls under an ease-of-use category.
One of the issues that you described was that you needed to completely re-implement a design to make changes, but this is not correct. The FPGA Editor tool allows you to make modifications to the ILA connections quickly and generate a new bitstream without going through a reimplementation stage. This functionality will continue to be improved in the Vivado tool chain as the debugger cores (the ChipScope name is being discontinued) are progressively more integrated with each release.