I'm having a problem in Quartus II v13 with a simple circular shift register. When I look at the logic with the RTL Viewer it is correct, but the circuit does not function correctly on the dev board. When I look at the Technology Map Viewer (Post-Fitting) I see that the clock only goes to stage zero of the shift register, the remaining stages are fed by the same clock via a CLKCTRL block. Sometimes re-arranging the circuit removes this block and then the circuit then functions correctly. What am I doing wrong?
Related
I am new to the field of ASIC design. I am trying to synthesize my code but am facing a problem when synthesizing. The tools used are Openlane and technology node is GF180 nm. The issue is that when synthesizing verilog blocks such as following are not completely synthesized and only partially synthesized. e.g.
//a is a single bit value with value 0 or 1
//f is a 8 bit vector and fin is a 16 bit vector
//depending on the value of a, either the first half or the second half of the fin goes to f
case (a)
0: begin
f=fin[7:0];
end
1: begin
f=fin[15:8];
end
The problem is that after the net-list is generated only the first half of the fin is connected and the rest of fin is removed i.e. only the condition for 1st case block is synthesized rest is removed (in optimization pass I presume). I have confirmed this from the netlist as well as gds generated where the pins for fin[15:8] are unconnected.
I have tried to create illusions in the code by creating a dummy register and connecting the unused part of input fin to that register but to no avail. The net-list still does not connect the upper parts of fin to anything. The above sample code is part of a larger code block and there are more case and if statements on top of this block. I am expecting a chain of multiplexers to be used to synthesize the logic. I am hoping if anyone can tell what kind of coding style can be opted to avoid this problem? How can this logic be written so that this issue does not arise for other designs?
I have a signal that checks if the data is available in memory block and does some computation/logic (Which is irrelevant).
I want a signal called "START_SIG" to go high X-time (nanoseconds) before the first rising edge of the clock cycle that is at 10 MHz Frequency. This only goes high if it detects there is data available and does further computation as needed.
Now, how can this be done? Also, I cannot set a delay since this must be RTL Verilog. Therefore, it must be synthensizable on an FPGA (Artix7 Series).
Any suggestions?
I suspect an XY problem, if start sig is produced by logic in the same clock domain as your processing then timing will likely be met without any work on your part (10MHz is dead slow in FPGA terms), but if you really needed to do something like this there are a few ways (But seriously you are doing it wrong!).
FPGA logic is usually synchronous to one or more clocks,generally needing vernier control within a clock period is a sign of doing it wrong.
Use a {PLL/MCM/Whatever} to generate two clocks, one dead slow at 10Mhz, and something much faster, then count the fast one from the previous edge of the 10MHz clock to get your timing.
Use an MCMPLL or such (platform dependent) to generate two 10Mhz clocks with a small phase shift, then gate one of em.
Use a long line of inverter pairs (attribute KEEP (VHDL But verilog will have something similar) will be your friend), calibrate against your known clock periodically (it will drift with temperature, day of the week and sign of the zodiac), this is neat for things like time to digital converters, possibly combined with option two for fine trimming. Shades of ring oscs about this one, but whatever works.
How to write in verilog and/or system verilog a normally open switch with delays with the following functionality: when pressed once it outputs 1 and stays 1 when depressed, when pressed a second time it outputs 0 and stays 0 when depressed. The 1 output is instantaneous upon pressing, the 0 output only occurs if the button is pressed for a determined time. This is essentially how the power button in desktops work: if computer is off pressing the button starts the computer but, if the computer is on, the button requires to be pressed for several seconds.
I am new to verilog; I would appreciate an actual verilog code of how to do this, including FSM if needed
Thanks a bunch
Cesar
For any logic require a past value/state, it should consider a FSM. Write down all the state you need. And consider the relationship between output and different state.
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.
I've been coding a 16-bit RISC microprocessor in Verilog, and I've hit yet another hurdle. After the code writing task was over, I tried to synthesize it. Found a couple of accidental mistakes and I fixed them. Then boom, massive error.
The design comprises of four 16-bit common buses. For some reason, I'm getting a multiple driver error for these buses from the synthesis tool.
The architecture of the computer is inspired by and is almost exactly the same as the Magic-1 by Bill Buzzbee, excluding the Page Table mechanism. Here's Bill's schematics PDF: Click Here. Scroll down to page 7 for the architecture.
The control matrix is responsible for handling when the buses and driven, and I am absolutely sure that there is only one driver for each bus at any given instance. I was wondering whether this could be the problem, since the synthesis tool probably doesn't know this.
Tri-state statements enable writing to a bus, for example:
assign io [width-1:0] = (re)?rd_out [width-1:0]:0; // Assign IO Port the value of memory at address add if re is true.
EDIT: I forgot to mention, the io port is bidirectional (inout) and is simply connected to the bus. This piece of code is from the RAM, single port. All other registers other than the RAM have separate input and output ports.
The control matrix updates a 30-bit state every negative edge, for example:
state [29:0] <= 30'b100000000010000000000000100000; // Initiate RAM Read, Read ALU, Write PC, Update Instruction Register (ins_reg).
The control matrix is rather small, since I only coded one instruction to test out the design before I spent time on coding the rest.
Unfortunately, it's illogical to copy-paste the entire code over here.
I've been pondering over this for quite a few days now, and pointing me over to the right direction would be much appreciated.
When re is low, the assign statement should be floating (driving Zs).
// enable ? driving : floating
assign io [width-1:0] = (re) ? rd_out [width-1:0] : {width{1'bz}};
If it is driving any other value then the synthesizer will treat is as a mux and not a tri-state. This is where the conflicting driver message come from.