Replies: 5 comments 9 replies
-
Hey Nik!
Thank you very much! :D
This is really amazing! I was also playing with the internal JTAG primitives in Xilinx FPGAs. I tried openOCD'S "tunneling" concept, which is not very well documented... The "remapping" approach you are using seems to be much more straightforward (and way better documented 😉).
Hmm, that's interesting... Maybe it is just a sampling issue on the JTAG adapter's side? openOCD provides a commend to "shift" the actual data point:
Anyway, great to see that it works!
I'm glad that you want to provide your setup! Right, I'd prefer to keep the base repository / base core as platform-independent as possible. So, how about adding a new setup to https://github.com/stnolting/neorv32-setups? We already have some platform-specific setups there that also use FPGA-specifc IPs. What do you think about that? |
Beta Was this translation helpful? Give feedback.
-
Hey Stephan,
This is really great! I would actually like to make use of this concept
also for the Lattice ECP5, aside from the Cyclone V that I use. For the
factory tester that I built, I also noticed that I have to generate the TDO
in an unclocked process, which is luckily documented in the Lattice
datasheet, but at the same time very annoying. It would be better if
OpenOCD could be told that the TDO comes one clock cycle later.
In any case, I totally agree with you to keep the code clean and platform
independent. However, what could be done, and this is something I do in
many of my own projects, is to have a directory 'portable' or
'platform_dependent', with modules with the same names but different
implementations for different vendors. In most cases I also have a VHDL
only implementation of these blocks for simulation purposes. Would this be
an approach that you support?
Best regards,
Gideon
Message ID: ***@***.***
com>
… |
Beta Was this translation helpful? Give feedback.
-
Wouldn't it be great if the VHDL built-in configuration mechanism would
actually work? The problem you will run into when trying this is that with
this method you generally compile all code, and your configuration selects
which architecture to use. However, you are not able to compile, let's say,
an architecture with a Lattice primitive in Quartus or Vivado. So your file
set has to be different for different vendors. In this situation, using a
configuration as a top level doesn't add any value.
In the company where I work, if we need different architectures for one
entity, we keep these in different files. For instance
neorv32_debug_dtm.vhd is then the entity, and
neorv32_debug_dtm-lattice_ecp5.vhd is then the vendor specific
architecture. When creating your project, you simply include the correct
architecture file. For simulation you take neorv32_debug_dtm-sim.vhd
which links
the bus functional model (BFM).
Message ID: ***@***.***
… com>
|
Beta Was this translation helpful? Give feedback.
-
Thanks for your feedback @stnolting and @GideonZ. I think we have a workable concept:
|
Beta Was this translation helpful? Give feedback.
-
Hi! I'm trying to follow some of the indications here to apply the same concept to Xilinx FPGAs. I'm having a lot of trouble, though, maybe because I'm also using the Digilent HS1 device, which I believe adds a little bit of complexity. It looks like I need to instantiate a BSCAN to JTAG converter (or maybe four, one per each USR? but how would I connect them?), but I haven't been able to have openOCD recognize the riscv core. I can't really provide any of the configurations I've tested because I've tried almost anything... so nothing I could provide would be very useful. Do you guys have any indication on what should be the best way to proceed? |
Beta Was this translation helpful? Give feedback.
-
Hi there! Thanks for this amazingly good documented risc-v processor!
I'm playing around with it on a Cyclone IV E and it's a blast. One thing that was a bummer is, that I'd need an additional JTAG or UART connection to load and or debug the system. I wanted to improve on that and found the excellent blog of tomverbeure that describes how the integrated JTAG primitive of the FPGA can be used.
Basically Intel FPGAs allows the user to use two special ir addresses (10 bit) for their own purpose. USR0 at
0x00c
and USR1 at0x00e
. For those (and only those) addresses a user can supply the tdo signals that then are outputted from the FPGA.OpenOCD does not care about the different ir address or even the size difference. One can set the new addresses simply with:
To do this all I modified the existing
neorv32_debug_dtm
: removedbypass
andidcode
registers, changed addresses ofdtmcs
anddmi
and (strangely) needed to move the tdo assignment out into an asynchronous process.The modified `neorv32_debug_dtm` entity
Additionally the toplevel needs to instantiate the
cycloneive_jtag
entity (in my case) and hook up the user JTAG signals.The toplevel entity
With this in place one can connect with the normal upstream OpenOCD by sourcing the
interface/altera_usb_blaster.cfg
script and the mentioned ir address configs. Loading executables and general debugging with gdb is working fine albeit a tad slow.OpenOCD output
My main point for discussion is: How can I provide this information/system back to the community? I think it would be useful to the community. But I'd also guess that neorv32 is not supposed to depend on platform specific VHDL and won't incorporate these changes directly.
Would you approve a pr if some of these changes are made configurable with generics?
How and where should one document this system?
Bonus: If I'm not mistaken then Xilinx FPGAs have a similar system with the primitive
BSCAN
entity which could benefit from this as well. But I can't test it as I have no such FPGA.Beta Was this translation helpful? Give feedback.
All reactions