FPGAs have tri-state outputs :
sda <= 'Z' when dout='1' else '0';
There are also sometimes optional internal pull-ups, but they are not meant to drive external circuits, so an I2C bus will need an actual pull-up resistor.
VHDL std-logic type has 'H' and 'L' values to simulate pull-up and pull-downs.
You can write
in the test-bench to ...
An isolation transformer will make it safe to touch live, but definitely not live and neutral simultaneously.
Another option is a RCD (residual current device). I purchased a sensitive one which trips at 10mA leakage current to ground, which is safer than the 30mA one which protects the whole house. You will still get a large jolt if you touch the wires, ...
Headers are pretty cheap and make a lot of sense over a wide range of quantities, down to 1 piece. A 5 x 2 header takes up very little space, even less in 2mm pitch. The connections usually end up free of flux so they don't crud up the mating connector.
For really high volume, you can use a fixture with spring-loaded 'pogo' pins which can be cheaper per ...
You are missing the very first thing I'd use, which is a isolation transformer. The next most useful device is the variac. Your redundant fuse and circuit breaker are just silly.
When using both a variac and a isolation transformer, put the variac in front of the isolation transformer. This is because many common isolation transformers are toroids that ...
Note that FPGA design tools sometimes provide a specific open-drain primitive in their library. E.g. in Quartus II you can write
sda: opndrn PORT MAP (
a_in => sda_wire,
a_out => sda_pin
This shouldn't make any difference on a bidir IO pin, but it may make a difference if you need to ...
Some problems with your code:
1) Testbench: You are not initializing the reset signal or driving it to a valid state during the simulation. Fix this.
2) Testbench: Your clock period is 40 ns but your testbench waits for 20 ns to change the inputs. This is faster than the system can respond to changes. Probably not what you want to do for basic behavior ...
I think what you are seeing is the result of the internal GSR signal falling at t=100ns. This signal prevents the flip flops from changing state while it is asserted. It's sort of like an internal reset. I'm not sure if you can change the GSR behavior in modelsim. But what you can do is simply add a 100 ns delay before starting the clock signal so you avoid ...
It is a common misconception that initial blocks cannot ever be synthesised.
In fact, for FPGAs, they can in most cases be synthesised. In fact the use of initial blocks is quite common. You can use them to set the power-on value of structures such as RAMs, ROMs, and registers.
This is not bad practice at all, and helps with both simulation and synthesis ...
Your testbench isn't connecting any signals to the DUT outputs (q, r, busy, ready, count). You declared the signals in the testbench but didn't make the connections.
how would i do that ? everywhere i search for a testbench example i do not see 'the connection' you are talking about.
You do it the exact same way you connected the inputs:
// instantiate ...
In your first code sample, you have a low active reset (if (~Reset) D <= 0). And in the testbench you hold Reset low for most of the simulation. As expected this results in D being 0.
In your second code sample you have a high-active reset (if (reset) q <= 0 ) which will naturally behave differently.
The problem is with this block:
clk = 1;
clk = 0;
It will only run when clk is high, since you have @(clk) as the sensitivity list at the beginning of the block. A more typical way to generate your clock is this:
initial clk = 0;
always #20 clk = ~clk;
Actually, though, your original code might work fine ...
A general approach is to use more abstracted tests as you progress up the stack in terms of design complexity. Yes, you need to trust the tools (and the checking tools like logical equivalence proofs), but for a whole-fpga design (a) there won't be space for a testbench, and (b) exhaustive coverage will take a long time.
A good approach is to use exhaustive ...
When I run your code on 2 different simulators, I get compile warnings about port size differences for d and qd. Your counter declares them as 8-bit wide, but you connect 1-bit signals to them. Don't you get warnings? If not, try it on edaplayground.
In test_b, declare them as 8-bit:
reg [7:0] d;
wire [7:0] ...
You might consider writing a VHDL package to read and write some simple image format, such as XPM which, being text, is probably easier to handle than binary files such as bmp,jpg etc.
Just use GIMP or other image processing software to export the images you want to XPM, and import your testbench's results.
No. In the past I have made a Matlab script to convert an image into a format the is easy to read into a testbench such as an rgb image stored in a simple format like hexadecimal rgb stored one pixel per line ( use the textio library to parse the file line by line). For my tests There was some assumed row/column ordering and a fixed size image. Then I run ...
If you are to use an external SRAM in your FPGA platform, then you need not only the "cycle accurate", but also (mostly) "timing-accurate" model, if you want something to work. The timing depends on particular memory chip and manufacturer, so the normal way is to download the model form manufacturer's site.
Again, you keep repeating your questions, but ...
I found that there are basically four options:
Include the CPU (NIOS-II) itself in the simulation.
Use an existing "open core" CPU design.
Use a "bus functional model" (BFM).
Create my own simulatable CPU and bus master interface.
I ended up using option 4.
The problem with option 1 is that the full-blown CPU is complex and simulates slowly. On chips that ...
Lamp ignition on a HID lamp is electrically very noisy, being as it involves very high voltage pulses for arc ignition.
I would expect the problem here to be RF pickup by the USB leads during lamp ignition (You may also see HDMI dropping out), cure is probably some ferrites as common mode chokes on the ballast DC connections (And maybe also on the USB ...
Prompt 35 'restart' and you get a warning that component DUT is not bound. That's legal in VHDL.
Your instantiated component name doesn't match the name of the entity you compiled.
Modelsim has verror that returns an expanded definition of what causes the error:
vsim Message # 3473: The specified component has not been explicitly
bound and no ...
Using only the ESR from the datasheet (ideal wires...):
Current is practically zero before discharging and jumps to 10A, hence the drop. Initial linear discharge is expected due to constant current.
The larger drop you see is certainly due to wires, switches etc.
To be more specific, let's consider 3 steps:
charging: capacitor practically reached its max....
I would try to use an analog mux with low on resistance such as the adg1606. https://www.analog.com/en/products/adg1606.html
It has less than 8ohms resistance over most of your temperature range and likely won't have a problem in cold where the mux performance isn't specified.
I've rounded up all the good advice from the comments into an answer.
Generates a slower strobe from a faster clock.
entity ClockStrobe is
CLOCK_PERIOD : time := 20 ns;
STROBE_PERIOD: time := 2 ms
reset : in ...
Wish I could comment, b/c there are a lot of syntactical issues here.
You defined a type called H and then tried to assign something to the type: H(0) := v_adcValue which is illegal and may explain the first part of the error. You must define the type and then declare a variable or signal of the defined type, which can then receive assignment.
It looks ...
You have made an architecture for "reg_A" but try to instantiate a component "dut" with definition name "rega" meanwhile such component is not exists in your generated library(work).
You also did not connect the "SEL" of the entity port to local defined "s" that most probably is a typing mistake.
I have changed your code and it seems that its simulation is ...
You can indeed use initial values in Verilog or VHDL but they reduce the portability of your design. They are therefore to be avoided and are not recommended.
Your design will behave differently depending on the target device. Synthesize it for a RAM-based FPGA (typ. Altera, Xilinx) and your design will work because the initial values will ...
1/ Is it bad practice?
It is perfectly fine and often done in test benches. But I assume that is not what you where alluding to. I would prefer to say it is rarely done. The reason is that it can not be synthesized for all FPGAs and definitely not for ASICs. This makes that your design can no longer be trusted as what you simulate may not match what the ...
I get 2 compile errors when I run your code on 2 different simulators. Did you try your code on edaplayground?
You didn't define REFCLK_PERIOD and you declared i_SysCLK as a wire. After making these 2 corrections, and assuming some value for REFCLK_PERIOD, I get output which clearly demonstrates that all 3 clock signals are toggling between 0 and 1. Un-...
I agree with earlier posters, but would go a bit further. Your life is valuable so it is worth spending some time and money to make a reasonably safe test rig.
0) Unless your application is very unusual you will probably find a [set of] suitable PSU[s] from a reputable manufacturer at a reasonable price. I avoid mains work where possible.
1) Keep all ...