Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
khan990@gmail.com wrote: > I am trying to simulate a chemical reaction in FPGA. > My basic FPGA architecure consists of 3 processes: (big snip) > I can communicate with this IP from PPC but in a very strange way. (snip) > CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal > DataFPGA = CHECKPPC6_mReadFromFIFO(baseaddr, 0); > I donot see the initial value from FPGA IP until I send an empty > useless value to IP input (which is > CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal). > In my view a simple software reset (CHECKPPC6_mReset) should have > initialized the IP and given me the output value I assign in > ASSIGN_VARS case of my IP. > My IP design is such that. IP asks the input of chemical molecules. > then perform reaction and wait for ACK signal from PPC to continue > with the next round. I have seen a few times that it is easy to be off by one when figuring the number of register stages needed to get data to where it is going. You might especially check the FIFOs, which might have registers on the input (or output) that you didn't take into account. The usual FPGA block RAMs are synchronous, which makes the FIFOs work a little different from some of the FIFO chips that are available. -- glenArticle: 156151
Thanks glen. Will it be wise to use software registers in this case? If yes, what changes do I need to make in user_logic.vhd? Thanks again.. :) On Thursday, December 19, 2013 9:40:28 PM UTC+1, glen herrmannsfeldt wrote: > wrote: > > > > > I am trying to simulate a chemical reaction in FPGA. > > > > > My basic FPGA architecure consists of 3 processes: > > > > (big snip) > > > > > I can communicate with this IP from PPC but in a very strange way. > > > > (snip) > > > > > CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal > > > DataFPGA = CHECKPPC6_mReadFromFIFO(baseaddr, 0); > > > > > I donot see the initial value from FPGA IP until I send an empty > > > useless value to IP input (which is > > > CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal). > > > In my view a simple software reset (CHECKPPC6_mReset) should have > > > initialized the IP and given me the output value I assign in > > > ASSIGN_VARS case of my IP. > > > > > My IP design is such that. IP asks the input of chemical molecules. > > > then perform reaction and wait for ACK signal from PPC to continue > > > with the next round. > > > > I have seen a few times that it is easy to be off by one when figuring > > the number of register stages needed to get data to where it is going. > > > > You might especially check the FIFOs, which might have registers on > > the input (or output) that you didn't take into account. > > > > The usual FPGA block RAMs are synchronous, which makes the FIFOs work > > a little different from some of the FIFO chips that are available. > > > > -- glenArticle: 156152
On Thursday, December 19, 2013 3:57:32 PM UTC+5:30, HT-Lab wrote: > On 19/12/2013 10:05, neer4j.iit.delhi@gmail.com wrote: > > > Tarang EDA has launched Cloud based VHDL functional verification tool to quickly with many new features which are not possible in Desktop/Offline Tools. > > > > > > No Bulky Installations > > > Fastest Simulation > > > Work as Teams > > > Work from anywhere > > > Platform Independent > > > > > > You can try it on http://www.tarangeda.com > > > > > > > We collect following information: > > 1.Information provided by you during registration > > 2.Cookies > > 3.Your content and project files > > 4.Your IP address in various log files > > 5.Geo-Location Information > > 6.Device Identifiers > > > > ough...... you might want to change this if you want to target any > > (serious) developers. > > Can you please tell what is wrong and what should be done? > > Hans > > www.ht-lab.comArticle: 156153
Hello, I have read in many places that the outputs of a finite state machine must = be set to their default values in order to avoid unwanted latches. However,= I have a design of an FSM in my mind in which some outputs at some states = must keep their old values. For example assume "a" is an output of the FSM.= Depending on the state, it can have one of these three assignments: a <=3D '0'; a <=3D '1'; a <=3D a; My question is if this is a good and common practice in designing FSMs for = FPGAs, i.e. if we latch some outputs at some states. Thanks!Article: 156154
Ehsan <ehsan.hosseini@gmail.com> wrote: > I have read in many places that the outputs of > a finite state machine must be set to their default > values in order to avoid unwanted latches. Unwanted latches come from the way behavioral verilog (and I believ VHDL) work. It is a separate question. > However, I have a design of an FSM in my mind in > which some outputs at some states must keep their > old values. For example assume "a" is an output > of the FSM. Depending on the state, it can > have one of these three assignments: > a <= '0'; > a <= '1'; > a <= a; This is the difference between Mealy and Moore machines. That only matters if you use a FSM generator. Otherwise, you can do anything that make logical sense. > My question is if this is a good and common practice > in designing FSMs for FPGAs, i.e. if we latch some > outputs at some states. Good practice might be using a, more or less, standard design for a Mealy or Moore machine. -- glenArticle: 156155
On Monday, December 23, 2013 3:55:45 PM UTC-5, Ehsan wrote: > Hello, >=20 >=20 >=20 > I have read in many places that the outputs of a finite state machine mus= t be set to their default values in order to avoid unwanted latches. Howeve= r, I have a design of an FSM in my mind in which some outputs at some state= s must keep their old values. You're misinterpreting what you've read. The 'assignment of a default valu= e to avoid latches' comes up IF you choose to write your FSM in the form of= a blob of combinatorial logic followed by a register. However, you can ch= oose to write your FSM in the form of a single clocked process that complet= ely avoids this problem. Google this and comp.lang.vhdl for 'two process s= tate machine' and you'll likely hit on all kinds of banter on the subject. = Don't believe any of the proponents of the 'two process' (or three process= ) approach when they discuss why 'two process' is superior (it's not). The bottom line is: - Writing it in the 'two process' form gains you nothing and will cost you = in terms of spending time with extra typing and extra verifying that you ha= ven't overlooked some signal inside the combinatorial process. - What you've read is not limited to FSMs, it applies to any synchronous de= scription. > For example assume "a" is an output of the FSM. Depending on the state, i= t can have one of these three assignments: >=20 > a <=3D '0'; >=20 > a <=3D '1'; >=20 > a <=3D a; >=20 Assuming that this is not combinatorial logic (i.e. the 'a' is an output of= a flip flop), then all of the above would be OK. If 'a' is not the output= of a flip flop, then the last assignment would create a form of latch whic= h would not be good in an FPGA design. >=20 > My question is if this is a good and common practice in designing FSMs fo= r FPGAs, i.e. if we latch some outputs at some states. >=20 Your question seems to have nothing to do with anything previous. The 'goo= d and common practice' is to accurately describe your design while avoiding= descriptions that result in a signal feeding back into its own logic witho= ut a flip flop in between. If you're asking is it OK to have 'a' not chang= e value while in a particular state, then yes that is very commonly done. = A simple example is a counter that has a count enable. If the count enable= is true, then you count, if not then the count remains unchanged. Kevin JenningsArticle: 156156
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 24 =D0=B4=D0=B5=D0=BA=D0=B0=D0= =B1=D1=80=D1=8F 2013=C2=A0=D0=B3., 0:55:45 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C= =D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ehsan =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0=D0=BB: > Hello, >=20 >=20 >=20 > I have read in many places that the outputs of a finite state machine mus= t be set to their default values in order to avoid unwanted latches. Howeve= r, I have a design of an FSM in my mind in which some outputs at some state= s must keep their old values. For example assume "a" is an output of the FS= M. Depending on the state, it can have one of these three assignments: >=20 >=20 >=20 > a <=3D '0'; >=20 > a <=3D '1'; >=20 > a <=3D a; >=20 >=20 >=20 > My question is if this is a good and common practice in designing FSMs fo= r FPGAs, i.e. if we latch some outputs at some states. >=20 >=20 >=20 > Thanks! If you made something like this: process(clk) begin if rising_edge(clk) then if reset =3D '1' then state <=3D first; ... else case state is when first =3D> a<=3D '0'; state <=3D second; when second =3D> a<=3D '1'; state <=3D third; when third =3D> a<=3D a; state <=3D first; when others =3D> null; end case; end if; end if; end process; there is no latches at all! Latches may arise in combinatorial logic. In fu= lly clocked logic there is no latches. Moreover, you can omit "a<=3Da;" in most cases: process(clk) begin if rising_edge(clk) then if reset =3D '1' then state <=3D first; ... else case state is when first =3D> a<=3D '0'; state <=3D second; when second =3D> a<=3D '1'; state <=3D third; when third =3D> state <=3D first; when others =3D> null; end case; end if; end if; end process;Article: 156157
On Tuesday, December 24, 2013 10:02:17 AM UTC-6, Ilya Kalistru wrote: > Moreover, you can omit "a<=3Da;" in most cases:=20 In a clocked process, you will usually get a "removing redundant assignment= " warning (harmless, except it is one more warning you have to look at and = dismiss after every synthesis run). But keep in mind, in the given registered process, 'a' becomes the output o= f an inferred register. If the OP is wanting a combinatorial output decoded from the state register= , then having a combinatorial output remember its last value will create a = latch, no matter how you do it. You could create an additional register whi= ch "remembers" the last output value, and select the output of that registe= r when it is desired to not change the output value. Or you can create a registered output that is set whenever the state is ass= igned to the desired states for that output. If the output is desired to be= a function of only the state, then this is fairly simple. If the output is= desired to be a function of the state and other inputs, it gets more compl= ex, but is certainly doable. AndyArticle: 156158
>>If the OP is wanting a combinatorial output decoded from the state register How it can be useful?Article: 156159
On 12/10/2013 11:43 AM, pfraser wrote: > david.middleton@gmail.com wrote: >> Hi Pete, >> >> We are just prototyping a similar board to talk to a AD9361. >> >> Are you progressing with the plan to interface through the GPMC, and >> if so what are your software resources? >> >> We are currently developing drivers with the intention of releasing a >> vhdl opencore & gpmc device driver but at this stage we are as vapour >> as everyone else (which is to say we are a reasonable way from being >> manufacturable). >> > > I got sidetracked, so haven't had much of a chance to look > at this yet. I'm a hardware guy, so I'd just be making > up the software is I go along. I'd certainly be interested > in the stuff that you're doing when I get back to this. > > It looks like the BeagleBone Black is a nice choice, > but there's contention for a couple of GPMC balls, so > the board would need to boot off the SD card (on-board > flash disabled in device tree). > > Are you using the black, or the white? > > Pete > I just wanted to throw this out there, in case it helps: http://www.kickstarter.com/projects/1575992013/logi-fpga-development-board-for-raspberry-pi-beagl I backed one for the BeagleBone, as it intrigues me. -JayArticle: 156160
Hello,
=C4=B0 have a code like this and i have to use SSD for outputs.
module telephoneConversation(clock, reset, caller, callee, areaCode, startE=
nd, letter, display, leds);=20
=20
input clock, reset, caller,callee; =09
input areaCode; // 0: city_A, 1: city_B
input startEnd; // 0: start, 1: end
input [2:0] letter; // a character (from the code) of 3 bits
output reg [27:0] display; // 4 displays of each 7 bits
output reg [7:0] leds; // represents the correctness of the guess
=09
reg [3:0] current_state; // current state of the circuitry
reg [3:0] next_state; // next state of the circuitry
reg [14:0] characterCount; // number of characters transferred=20
reg [12:0] transitionCounter; // counter to wait in the states
reg [1:0] areaCode_caller;
reg [1:0] areaCode_callee;
=E2=80=A6 // additional registers
// sequential part - state transitions
always @ (posedge clk or posedge rst)
begin
=E2=80=A6 =09
end
// combinational part - next state definitions
always @ (*)
begin
=E2=80=A6 =09
end
=09
// sequential part - control registers
always @ (posedge clk or posedge rst)
begin
=E2=80=A6 =09
end =09
// sequential part - outputs
always @ (posedge clk or posedge rst)
begin
=E2=80=A6 =09
end
=E2=80=A6 =09
endmodule
I have a ssd code like this
"`timescale 1ns / 1ps
///////////////////////////////////////////////////////////////////////////=
///////
// Company:=20
// Engineer:=20
//=20
// Create Date: 19:32:18 01/04/2010=20
// Design Name:=20
// Module Name: ssd=20
// Project Name:=20
// Target Devices:=20
// Tool versions:=20
// Description: This module drives the seven segment displays. It has got 4=
different inputs
// for the 4 digits on the board. It's inputs are not directly the bin=
ary numbers.
// You need to convert 4-bit hex values to their seven segment display=
equivalents.
// =20
// a0,b0,c0,d0,e0,f0,g0 belongs to digit0, rigth most digit on the boa=
rd.
// a1,b1,c1,d1,e1,f1,g1 belongs to digit1, 2. from the rigth digit on =
the board.
// a2,b2,c2,d2,e2,f2,g2 belongs to digit2, 3. from the rigth digit on =
the board.
// a3,b3,c3,d3,e3,f3,g3 belongs to digit3, left most digit on the boar=
d.
// =09
// The values that you connect to these inputs will appear on the disp=
lay digits.
// Thus, you just need to make the appropriate connections and should =
not concern
// about the rest.
//
// Dependencies:=20
//
// Revision:=20
// Revision 0.01 - File Created
// Additional Comments:=20
//
///////////////////////////////////////////////////////////////////////////=
///////
module ssd( clk, reset, a0,a1,a2,a3,b0,b1,b2,b3,c0,c1,c2,c3,d0,d1,d2,d3,e0,=
e1,e2,e3,
f0,f1,f2,f3,g0,g1,g2,g3,a,b,c,d,e,f,g,an0,an1,an2,an3
);
input clk, reset;// set clock and reset as input(1 bit)
input a0,a1,a2,a3,b0,b1,b2,b3,c0,c1,c2,c3,d0,d1,d2,d3,e0,e1,e2,e3,f0,f1,f2,=
f3,g0,g1,g2,g3;//set our display data as input(1 bit)
output reg a,b,c,d,e,f,g,an0,an1,an2,an3;//set outputs also as registers (1=
bit)
reg [2:0] state;//holds state number (3 bit)
reg [14:0] counter;//counter to slow the input clock(15 bit)
//in this always block the speed of the clock reduced by 25000 times so tha=
t display works properly
always @ (posedge clk) begin //state counter
if(reset) begin //synchronus reset
state <=3D 0; //if reset set state and counter to zero
counter <=3D 0;
end else begin //else the counter untill 25000
if(counter =3D=3D 15'h61A8) begin //if equal to 25000
if (state =3D=3D 3'b100) //if it is in the last state return to state 1
state <=3D 1;
else //else go one state up
state <=3D state + 1;
=09
counter <=3D 0; //0 the counter because after it reaches 25000
end
else
counter <=3D counter + 1; //if not 25000 add 1
end
end
//in this always block we give the inputs to the leds by choosing=20
//different display segment in each time
//!(In the button-pin sheet of the Basys, the 7-SEG numbers are assinged wr=
ong.
//To avoid confusion we corrected it while choosing an0,an1... So if you ju=
st enter
//pin numbers according to the sheet it will work fine.)
always@(posedge clk)
begin
if(reset)// if reset initilize the outputs
begin
an0 <=3D 1;
an1 <=3D 1;
an2 <=3D 1;
an3 <=3D 1;
a <=3D 1;
b <=3D 1;
c <=3D 1;
d <=3D 1;
e <=3D 1;
f <=3D 1;
g <=3D 1;
end
else if(state =3D=3D 3'b001) //state 1 gives the led outputs to the AN0=09
begin
an0 <=3D 1;
an1 <=3D 1;
an2 <=3D 1;
an3 <=3D 0;
a <=3D a0;
b <=3D b0;
c <=3D c0;
d <=3D d0;
e <=3D e0;
f <=3D f0;
g <=3D g0;
end
else if(state =3D=3D 3'b010) //state 2 gives the led outputs to the AN1 =
=09
begin
an0 <=3D 0;
an1 <=3D 1;
an2 <=3D 1;
an3 <=3D 1;
a <=3D a1;
b <=3D b1;
c <=3D c1;
d <=3D d1;
e <=3D e1;
f <=3D f1;
g <=3D g1;
end
else if(state =3D=3D 3'b011) //state 3 gives the led outputs to the AN2 =
=09
begin
an0 <=3D 1;
an1 <=3D 0;
an2 <=3D 1;
an3 <=3D 1;
a <=3D a2;
b <=3D b2;
c <=3D c2;
d <=3D d2;
e <=3D e2;
f <=3D f2;
g <=3D g2;
end
else if(state =3D=3D 3'b100) //state 4 gives the led outputs to the AN3=09
begin
an0 <=3D 1;
an1 <=3D 1;
an2 <=3D 0;
an3 <=3D 1;
a <=3D a3;
b <=3D b3;
c <=3D c3;
d <=3D d3;
e <=3D e3;
f <=3D f3;
g <=3D g3;
end
else //For other states default inputs and outputs
begin
an0 <=3D 1;
an1 <=3D 1;
an2 <=3D 1;
an3 <=3D 1;
a <=3D 1;
b <=3D 1;
c <=3D 1;
d <=3D 1;
e <=3D 1;
f <=3D 1;
g <=3D 1;
end
end
endmodule
"
how can i use ssd.v file in main file. How can i call functions. Where shou=
ld i do convert 4-bit hex values to their seven segment display equivalents=
?
Article: 156161New to FPGAs, not much understanding of what goes on inside them, and I may never get very far in that direction. I'm building an app on Cyclone II that involves some parallel 8-bit wide I/O busses connecting to device pins, and various routing and logic operations in btween the in and the out. I'm wondering whether it matters which pins are used for the I/O in terms of optimising the internal connections and processing within the device. As a converse example, would it matter at all if I scattered my bus I/O all over the place randomly. Or can these devices and their IDE magically still make it all work just as efficiently? I presume not. Are there any guidelines that a relative beginner would be able to understand?Article: 156162
On 02/01/2014 10:51, Bruce Varley wrote: > New to FPGAs, not much understanding of what goes on inside them, and I may > never get very far in that direction. I'm building an app on Cyclone II that > involves some parallel 8-bit wide I/O busses connecting to device pins, and > various routing and logic operations in btween the in and the out. I'm > wondering whether it matters which pins are used for the I/O in terms of > optimising the internal connections and processing within the device. As a > converse example, would it matter at all if I scattered my bus I/O all over > the place randomly. Or can these devices and their IDE magically still make > it all work just as efficiently? I presume not. > > Are there any guidelines that a relative beginner would be able to > understand? > > I don't use Cyclones but so far (based mainly on Lattice parts) I've never had a serious issue optimising my pin assignments for pcb layout and letting the FPGA tools worry about the insides. It's obviously easier for the tools if you don't push to the limits on capacity or speed. It's also normal that a pinout which is optimum for the pcb will cluster IO in sensible groups. If you are using different IO standards on different IO banks you do need to think about that (and of course to make sure that any pin you do assign can support the IO configuration you want). Michael KellettArticle: 156163
On Thu, 02 Jan 2014 18:51:44 +0800, Bruce Varley wrote: > New to FPGAs, not much understanding of what goes on inside them, and I > may never get very far in that direction. I'm building an app on Cyclone > II that involves some parallel 8-bit wide I/O busses connecting to > device pins, and various routing and logic operations in btween the in > and the out. I'm wondering whether it matters which pins are used for > the I/O in terms of optimising the internal connections and processing > within the device. As a converse example, would it matter at all if I > scattered my bus I/O all over the place randomly. Or can these devices > and their IDE magically still make it all work just as efficiently? I > presume not. > > Are there any guidelines that a relative beginner would be able to > understand? Back when I was sociable enough to work with other people, Xilinx would push the FPGA guys to let the Xilinx tools assign pins to signals. Since they were also the board designers, they usually reacted to that with about as much enthusiasm as you might to the idea of eating soup made with lawn clippings. They generally assigned pins in some "sensible" grouping by port; the preference was for busses to be physically grouped, etc. Sometimes they'd let the Xilinx tool assign pins, but would then nail that down for subsequent design iterations, so that the board layout would not change. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156164
Tim Wescott <tim@seemywebsite.really> wrote: > On Thu, 02 Jan 2014 18:51:44 +0800, Bruce Varley wrote: >> New to FPGAs, not much understanding of what goes on inside them, and I >> may never get very far in that direction. I'm building an app on Cyclone >> II that involves some parallel 8-bit wide I/O busses connecting to >> device pins, and various routing and logic operations in btween the in >> and the out. I'm wondering whether it matters which pins are used for >> the I/O in terms of optimising the internal connections and processing >> within the device. (snip) > Back when I was sociable enough to work with other people, Xilinx would > push the FPGA guys to let the Xilinx tools assign pins to signals. Since > they were also the board designers, they usually reacted to that with > about as much enthusiasm as you might to the idea of eating soup made > with lawn clippings. As well as I understand it, early FPGAs didn't have as much routing resource, such that it mattered more where the pins went. Later, some added extra routing around the edge to make it easier to get the pins where you wanted them. > They generally assigned pins in some "sensible" grouping by port; the > preference was for busses to be physically grouped, etc. Sometimes > they'd let the Xilinx tool assign pins, but would then nail that down for > subsequent design iterations, so that the board layout would not change. Also, more recent FPGAs allow different I/O voltages for different sets of pins. That sometimes restricts which signals come out where. -- glenArticle: 156165
On 1/2/14, 5:51 AM, Bruce Varley wrote: > New to FPGAs, not much understanding of what goes on inside them, and I may > never get very far in that direction. I'm building an app on Cyclone II that > involves some parallel 8-bit wide I/O busses connecting to device pins, and > various routing and logic operations in btween the in and the out. I'm > wondering whether it matters which pins are used for the I/O in terms of > optimising the internal connections and processing within the device. As a > converse example, would it matter at all if I scattered my bus I/O all over > the place randomly. Or can these devices and their IDE magically still make > it all work just as efficiently? I presume not. > > Are there any guidelines that a relative beginner would be able to > understand? > > Generally (especially if the signal go into logic that will use carry chains etc) there are some pinouts that are "better" than other, being faster and/or not needing to use extra logic resources to help with the routing. The routing matrix from pin to internal is generally no where near complete, but generally flexible enough to handle most "normal" cases, especially if you can let the system use internal logic cells to help routing, There normally are a few signals that do need extra care. Signals like clocks sometimes need to be placed on one of a limited set of pins. Differential pairs need to be on related pins, so assigning one will assign the other. Often pins are grouped for signal type/io voltage, so if you have multiple types, you need to be sure you assignments are compatible with the ability of the device. Some tight timing conditions (like a DDR Memory or other high speed bus) may require specific pinouts to meet full timing, these can often also have board layout issues, so these really need to be worked out with an understanding of both. Ideally, you would have time to completely design the FPGA before laying out the board, so you can easily work out the trades knowing everything that is important. Much more often, you need to make good guesses based on experience up front, and hope that both paths can make it work. If you aren't pushing the FPGA, you can normally get away with a lot of flexibility in pinout. The Altera tool does have the ability to check if a pinout is "feasible", which you should check as a minimum.Article: 156166
On Thursday, December 26, 2013 12:23:50 PM UTC-6, Ilya Kalistru wrote: > >>If the OP is wanting a combinatorial output decoded from the state regi= ster > How it can be useful? I'm not sure exactly what you are asking.=20 Why someone would create outputs which are merely decoded from the state? B= ecause they can? If the state machine is one-hot encoded and the output is = only asserted for one state, then the bit for that state IS the output.=20 Otherwise, as long as the decoded outputs are sampled on the same clock as = the FSM, decoding glitches don't matter. Combinatorial state machine outputs are one of the few good reasons to use = a 2-process coding pattern. It is possible to create combinatorially decode= d outputs from an FSM in a single, clocked VHDL process, but it requires a = separate case statement from the next-state-assigning case statement and th= e state register has to be a variable instead of a signal. AndyArticle: 156167
Hello, is there a special term for a register that is not required to preserve its content longer than the next clock cycle? What I'm looking for is the following construct always @(posedge clk) begin myReg <= b'x; case (state) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156168
(web browser got trigger-happy with the previous post... trying again). Is there a special term for a register that is never required to keep its contents for longer than the next clock cycle? I'm thinking about the following code: always @(posedge clk) begin myReg <= 1'bx case (state) 123: myReg <= someValue 234: myReg <= someOtherValue default: /* no assignment to myReg */ end The background is that reuse of the resource is possible across different states. Now how would I call such a register? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156169
Hi Robert, I am also doing some work on the Cyclone V (CVEA5) and in my case Quartus software is still not able to synthesize a HMC for the FPGA that I want to use. Not even to use a soft controller with the same pins and functionality. They are looking into this issue. In my case I need to use Quartus 13.1 since it is the only one that has support for the FPGA that I want to use. Regards, Filipe On Friday, November 15, 2013 12:30:59 PM UTC, baum wrote: > Hi, > > > > I try to implement a DDR3 hard memory controller in a Cyclone v device > > a 5CGXFC3B6F23C7. > > > > I created an DDR3 hard memory controller IP core with the Megawizard, > > integrated the core in my design and added my design files in Quartus. > > > > The fitter of Quartus gives following error message > > > > Error (15332): Port SHIFTEN of cyclonev_pll_reconfig > > "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|Ddr3MemCtrl_000 > > > > 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11 > > connections, but the maximum > > bus width of port SHIFTEN is 9 > > > > In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as > > far as I know the Cyclone Pll has only 9 clock outputs so I assume the > > error message refers to this and barks about the two additional clock > > outputs. > > > > In the Megawizard there is no switch to select the number of clock > > outputs of the hard memory controller. > > > > I tried to synthesise the example created by the Megawizard, but the > > funny thing is this example is not for the Cyclone V device I specified > > in Quartus and the fitter ends with an error message too. > > This time not about the Pll but about some errors with output pins. > > > > So my question is: > > Has anybody implemented successfully a design with a DDR3 hard memory > > controller in a Cyclone v device or stumbled on the same error message > > as above. > > > > Btw. I use Quartus 13.1 according to Altera the latest version but IMHO > > not the greatest. > > > > RobertArticle: 156170
In article <6LydnaJSFucEclfPnZ2dnUVZ_jKdnZ2d@giganews.com>, mnentwig <24789@embeddedrelated> wrote: >Is there a special term for a register that is never required to keep its >contents for longer than the next clock cycle? > >I'm thinking about the following code: > >always @(posedge clk) begin > myReg <= 1'bx > case (state) > 123: myReg <= someValue > 234: myReg <= someOtherValue > default: /* no assignment to myReg */ >end > >The background is that reuse of the resource is possible across different >states. >Now how would I call such a register? Don't know of any specific name for such a register. It's still just a register. Now, me I loathe to actually introduce X's into code as you've done. (This goes against many coding suggestions). X's can mean many things - your use of the 'X' is to tell the synthesis tool it's a don't care, and can optimize accordingly. I'd just assign it to one of the already decoded states (i.e. someValue, or SomeOtherValue), or just gate the enable and not change the state at all, and not worry about any other possible (real or imagined) optimizations. Regards, MarkArticle: 156171
Thanks! I'd consider the "X" merely a formalism. I don't want to promote it as a coding style (discussion here: http://www.arm.com/files/pdf/Verilog_X_Bugs.pdf) But if I have a pipelined algorithm where the sharing of resources is clearly mapped out, the situation is fairly straightforward (it would look like Tetris bricks on a spreadsheet). What I'm looking into is resource sharing in an FPGA, a dual-port RAM and MAC (and this is BTW a toy project, not work related) "Transient" register didn't show up on Google, at least it seems to have no other meaning. Maybe I'll use that. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156172
mnentwig <24789@embeddedrelated> wrote: > is there a special term for a register that is not required > to preserve its content longer than the next clock cycle? > What I'm looking for is the following construct > always @(posedge clk) begin > myReg <= b'x; In days past, there was dynamic logic. Intel used it at least through the 8086 and 8088, which gives them a minimum clock frequency, otherwise the registers lose the data. Besides the extra instrutions, the Z80 was built with static logic, such that the clock could stop, or slow down to 1Hz, useful for debugging. I haven't followed them so close, but I believe that CCDs would be considered dynamic logic. There also used to be dynamic shift registers, up to about 512 bits in an 8 pin package. Again, you have to keep shifting or the bits fade away. I believe that you can write pass transistors in verilog, which, along with the capacitance of an MOS gate (and wiring) would allow generation of such dynamic logic. I don't believe that any FPGAs allow for it, though. -- glenArticle: 156173
In article <P-KdnbFyPLEVgVbPnZ2dnUVZ_rqdnZ2d@giganews.com>, mnentwig <24789@embeddedrelated> wrote: >Thanks! > >I'd consider the "X" merely a formalism. I don't want to promote it as a >coding style (discussion here: >http://www.arm.com/files/pdf/Verilog_X_Bugs.pdf) >But if I have a pipelined algorithm where the sharing of resources is >clearly mapped out, the situation is fairly straightforward (it would look >like Tetris bricks on a spreadsheet). > >What I'm looking into is resource sharing in an FPGA, a dual-port RAM and >MAC (and this is BTW a toy project, not work related) > >"Transient" register didn't show up on Google, at least it seems to have no >other meaning. Maybe I'll use that. Well, the register's not really transient, but it's definition changes according to state correct? Quite a while a ago I had something similar - some algorithm I'd designed with the help of a spreadsheet. Something where the registers definitions changed according to state. (It may have been an FFT, but I don't recall). Anyway, the algorithm worked itself out in the spreadsheet, and I then color-coded the "registers" along the time access to account for every register in hardware. The color indicated the actual hardware register, the position in the spreadsheet represented where it was (statewise) in the algorithm. It was easy to visualize the whole algorithm and how many registers it needed this way. I ended up naming the register in the RTL the color of the cell in the spreadsheet. Had some confusing conversations with my back end folks. 'Uh Mark, we're having timing closure problems between "Blue" and "Red"'... heh. I've never needed anything like this since. Most of my designs now are fully pipelined. And to tell the truth if I did need something like it now, I'd probably just create the extra registers with wild abandon, and let synthesis do with it what it may... Regards, MarkArticle: 156174
>Well, the register's not really transient, but it's definition changes >according to state correct? True... maybe there is a better word. Simply "shared" could do. I think it's also not exactly encouraged by Verilog. It seems very difficult to code a shared register, until all the logic is in a single "always @(clk)" block. Virtual tristates are something I don't want to touch, somehow I suspect it wouldn't help the design tool. Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z