I am working on simulations of verilog builded digital logic and need to restart a simulation very often to see the changes. I am using Cadence SimVision to review the waveforms.
Is there a way to write commands in verilog for the SimVision environment? I mean things like probes and Parameters.
It is not Verilog but you can create a tcl file.
shm.tcl:
database -open waves -shm
probe -create your_top_level -depth all -all -shm -database waves
run
exit
Now to run your simulation use:
irun -access +r testcase.sv -input shm.tcl
It's not standard Verilog, but the Cadence tools (ncvlog, ncsim, Incisive) will allow you to set probes from within the Verilog/SV source using a system call.
Check for documentation for $shm_open and $shm_probe.
initial begin
$shm_open("waves.shm");
$shm_probe("AS");
end
That said, the answer from #Morgan is the recommended way to do it so that you can control it at runtime.
Related
I am using the python nidaqmx API to instruct a USB-6009 DAQ to output an analog signal when a tone plays. I am trying to use the API guidelines and also the previous stackoverflow question (Triggering an output task with NIDAQmx) but still need help.
The timing of the tone is set using Psychopy, a python-based behavioural task package.
The general format of this would be:
if tone = on:
trigger_digital_output
I just cannot figure out the code from the nidaqmx documentation to trigger the analog output. Additionally, will I need to specify a digital input (USB-6009 will be connected by USb to my computer).
Thankyou
According to its specifications, the USB-6009 does not have any hardware triggers for analog output, and only a digital edge trigger for analog input.
So for your analog output task, you would use the same approach as the topic you referenced: use stop() and start() to begin the output each time you want to generate it.
The Digital I/O on the USB-6009 is only software-timed: the input or output happens on-demand, each time you call the read_one_sample_one_line() or write_one_sample_one_line() functions.
To get started with the full DAQ commands, there are a few Python examples on GitHub
analog output
digital output
digital input
I am able to build the code in modelsim but, when simulation getting below error:
addr_x, driven via port connection, is multiply driven (44) Line :49
addr_f, driven via port connection, is multiply driven (46) Line :49
s_ready_x, driven via port connection, is multiply driven (44) Line :49
s_ready_f, driven via port connection, is multiply driven (46) Line :49
How can I resolve this? (system verilog)
There is no simple* fix: You have to change your design. You might even have to go "back to the drawing board" and fundamentally change your design.
In each of the ctrlpath.., modules you output an address. Thus you drive the same net from different outputs. You somehow have to distinguish which of those you are really going to need. Thus you need to add a multiplexer which 'knows' which on to pick.
The "multiple driven" error is a recurring question appearing on Stack Overflow and Electrical engineering. What you have done is connecting multiple output ports together. In electrical engineering we call this 'shorting outputs together'. The term shorting is important as it is effectively a short circuit. This is the equivalent circuit:
Some outputs will be high and others are low. The ones which are high will try to drive the output high opening a current path from the VCC to the output pin. The ones which are low will try to drive the output low. They open a current path from the output to ground. Together they form a short circuit between your VCC and ground.
*Do not think you can easily solve this with tri-state drivers. Theoretical it may seem possible, practically you really, really don't want that.
Here is one of the messages from VCS compilation:
Error-[ICSD] Illegal combination of drivers
design.sv, 38
Illegal combination of structural drivers.
Variable "s_ready_x" is driven by multiple structural drivers.
This variable is declared at
"design.sv", 38: logic s_ready_x;
The first driver is at "design.sv", 50: ctrlpatho c( .clk (clk), .reset
(reset), .wr_done_f (wr_done_f), .wr_done_x (wr_done_x), .addr_x
(addr_x), .addr_f (addr_f), .m_valid_y (m_valid_y), .c ...
The second driver is at "design.sv", 45: ctrlpathx x( .clk (clk), .reset
(reset), .s_ready_x (s_ready_x), .addr_x (addr_x), .wr_done_x
(wr_done_x), .wr_en_x (wr_en_x), .s_valid_x (s_valid_x));
it just propagates the issue to the top-level module, but gives correct locations of the drivers.
The problem is, that both ctrlpathf and ctrlpatho drive the same signal with output ports. The rule of thumb is:
you cannot drive the same variable with multiple drivers.
System verilog just adds this requirement to the standard and it gets checked for the specific system verilog blocks.
To fix it
you need to review your program, in case you just made a mistake.
verilog allows you to multiply drive net types and defines rules for the results. If you really want to have multiple drivers, you would need to declare those ports as wires or similar and change the code to reflect it. They can be multiply driven with the assign statements.
An interesting issue arose with a device whose SWD_CLK pin is shared as a 'device boot mode' pin (ROM/Flash boot, etc.). The specification states that the SWD_CLK should be held high for some time before functioning as SWD_CLK.
The origen_swd plugin drives the clock high to 'enable' it, so the timeset for this pin must be 'return low' in order to clock. But, when I try to drive this high and hold it high, it begins clocking. Is there a way to disable the timeset for some time, then re-enable it when ready?
The workaround is to change the origen_swd to accept an option to either drive high or drive low to enable, then change the timeset in my application to return high.
Using metaprogramming to just grab and edit instance variables of the timeset may also be a solution, but is there a supported API to handle the tasks like the above?
Thanks
The way to do this would be by making two timing options for the given pin, one with the return low and one without.
tester.set_timeset "mode_entry", 40
pin(:swd_clk).drive!(1)
# Sometime later once in mode
tester.set_timeset "func_swd", 40
If the tester supports (e.g. V93K) you can also define multiple wave forms for a pin within the same timeset, as shown at the end of this guide section - http://origen-sdk.org/origen/guides/pattern/timing/#Complex_Timing
Then you would just have a single timeset selection and control the wave you want on the pin like this:
pin(:swd_clk).drive!(1) # Would be defined in the timing as always high
pin(:swd_clk).drive!('P') # Now start the clk pulse
Both of these approaches will work in the generated ATE patterns, however at the time of writing I believe that OrigenSim does not yet support the second approach, so you will have to use the multiple timesets.
As an aside, you sound like you are only looking for a solution that works in simulation and not necessarily required to have the two types of waves within the final ATE pattern.
In that case, you could also try poking the testbench's pin driver force data bit, though I haven't tried this:
tester.simulator.poke('origen.pins.swd_clk.force_data[1]', 1);
If you have success with that, we should think about adding a convenience API to do this kind of thing in simulation:
pin(:swd_clk).force!(1)
According to the riscv-gcc compiler we are generated the binary file. This binary file data are feeding to rocket chip through this signals.
io_host_in_valid, input [15:0] io_host_in_bits
Here io_host_in_bits is 16-bit, so we are driving the 2-times for each instruction data in little-Endian mode.
We are not getting any response from Rocket core (HTIF).
How to simulate the Rocket core and if it is possible to simulate in Xilinx Vivado 2014 as well as debug the design.
Can any one help me about this
Regards,
Santhosh Kumar.
For more information on the Rocket Chip infrastructure, I recommend checking out the slides and videos from the first RISC-V Bootcamp.
The Rocket Chip can be simulated/debugged in two different ways: C simulator and Verilog. For information on using these modes, please consult the Rocket Chip README.
Yunsup's response on the riscv-hw mailing list:
I would take a look at http://riscv.org/tutorial-hpca2015/riscv-rocket-chip-generator-tutorial-hpca2015.pdf for an overview of interfaces and the FPGA setup.
Here’s a link to our test bench we use to test the rocket chip: https://github.com/ucb-bar/rocket-chip/blob/master/vsrc/rocketTestHarness.v. I would take a look at the htif_tick function, where the implementation can be found here at https://github.com/ucb-bar/rocket-chip/blob/master/csrc/vcs_main.cc, which calls a method on htif_emulator_t (https://github.com/ucb-bar/rocket-chip/blob/master/csrc/htif_emulator.h), which is inherited from htif_pthread_t (https://github.com/riscv/riscv-fesvr/blob/master/fesvr/htif_pthread.cc). You should also take a look at https://github.com/riscv/riscv-fesvr/blob/master/fesvr/htif.cc.
The host interface (HostIO) doesn’t take instructions directly, it’s a port for the front-end server (https://github.com/riscv/riscv-fesvr/tree/master/fesvr) to access target memory and the core’s control and status registers (CSR).
Referring to my earlier question here, I've been utilizing tri-states to work with a common bus. I still appear to have some implementation issues.
The tri-states use this type of code:
assign io [width-1:0] = (re)?rd_out [width-1:0]:{width{1'bz}};
Synthesis and translation goes well. No warnings or errors I wasn't expecting (I was expecting some since this is only a trial run and most of the components don't do anything and will hence be left unconnected). But when I actually try to implement it, all busses (there are three) output a 1111111111111111, or a -1, as converted by my binary to BCD converter. I checked if it really the case by instructing the control matrix to halt if the instruction received on the bus is -1, and it did halt.
The warning I receive for the tri-state being converted to logic is:
Xst:2040 - Unit Neptune_I: 16 multi-source signals are replaced by logic (pull-up yes)
Xst:2042 - Unit alu: 16 internal tristates are replaced by logic (pull-up yes):
And so on. Neptune_I is the top module, and I believe the multi-source signals it's referring to are the busses.
I have a doubt whether the pull-up yes is the root of this problem. Is it simply pulling everything up, causing it to be -1 all the time? But this does not make sense to me, because when the tri-state is activated, the signal should be controlled by whatever entity it is supposed to be controlled by.
I would like to take the time to replace the code with logic instead of the tri-states, but I'm unsure how to proceed.
Any help would be appreciated.
Are these signals going off-chip? Or are they internal to your FPGA? If the answer is the latter, you need to change your code. Modern FPGAs (like Spartan 6) no longer support internal tri-state buffers. They only exist for off-chip signals.
You need to write all of you internal code to avoid tri-state buffers. Create dedicated paths between components, no bidirectional interfaces.