Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 156150

Article: 156150
Subject: Re: ppc405 communication with custom ip ml403
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 19 Dec 2013 20:40:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen


Article: 156151
Subject: Re: ppc405 communication with custom ip ml403
From: Jasim Khan <khan990@gmail.com>
Date: Thu, 19 Dec 2013 13:32:15 -0800 (PST)
Links: << >>  << T >>  << A >>
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.
> 
> 
> 
> -- glen


Article: 156152
Subject: Re: New Cloud Based VHDL Simulator-Tarang
From: Neeraj Yadav <neer4j.iit.delhi@gmail.com>
Date: Fri, 20 Dec 2013 07:20:49 -0800 (PST)
Links: << >>  << T >>  << A >>
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.com

Article: 156153
Subject: Use of latches in FSMs
From: Ehsan <ehsan.hosseini@gmail.com>
Date: Mon, 23 Dec 2013 12:55:45 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Use of latches in FSMs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 23 Dec 2013 21:39:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 156155
Subject: Re: Use of latches in FSMs
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 23 Dec 2013 14:16:47 -0800 (PST)
Links: << >>  << T >>  << A >>
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 Jennings

Article: 156156
Subject: Re: Use of latches in FSMs
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Tue, 24 Dec 2013 08:02:17 -0800 (PST)
Links: << >>  << T >>  << A >>
=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
Subject: Re: Use of latches in FSMs
From: jonesandy@comcast.net
Date: Thu, 26 Dec 2013 09:25:16 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Andy

Article: 156158
Subject: Re: Use of latches in FSMs
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Thu, 26 Dec 2013 10:23:50 -0800 (PST)
Links: << >>  << T >>  << A >>
>>If the OP is wanting a combinatorial output decoded from the state register

How it can be useful?

Article: 156159
Subject: Re: Interface Xilinx KC705 to BeagleBone?
From: feverlabs <jay@feverlabs.org>
Date: Sun, 29 Dec 2013 09:32:38 -0500
Links: << >>  << T >>  << A >>
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.

-Jay

Article: 156160
Subject: Simple Telephone Conversation on Fpga board and SSD
From: mertserimer@gmail.com
Date: Mon, 30 Dec 2013 14:13:27 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 156161
Subject: Optimising pin allocation
From: "Bruce Varley" <bv@NoSpam.com>
Date: Thu, 2 Jan 2014 18:51:44 +0800
Links: << >>  << T >>  << A >>
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? 



Article: 156162
Subject: Re: Optimising pin allocation
From: MK <mk@nospam.co.uk>
Date: Fri, 03 Jan 2014 07:47:58 +0000
Links: << >>  << T >>  << A >>
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 Kellett


Article: 156163
Subject: Re: Optimising pin allocation
From: Tim Wescott <tim@seemywebsite.really>
Date: Fri, 03 Jan 2014 15:06:09 -0600
Links: << >>  << T >>  << A >>
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.com


Article: 156164
Subject: Re: Optimising pin allocation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 3 Jan 2014 21:15:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen
 

Article: 156165
Subject: Re: Optimising pin allocation
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 04 Jan 2014 00:54:38 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Use of latches in FSMs
From: jonesandy@comcast.net
Date: Sun, 5 Jan 2014 13:42:04 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Andy

Article: 156167
Subject: register naming
From: "mnentwig" <24789@embeddedrelated>
Date: Mon, 06 Jan 2014 11:55:38 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 156168
Subject: register naming
From: "mnentwig" <24789@embeddedrelated>
Date: Mon, 06 Jan 2014 12:02:01 -0600
Links: << >>  << T >>  << A >>
(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.com

Article: 156169
Subject: Re: Cyclone V hard memory controller
From: teixeirafms@gmail.com
Date: Mon, 6 Jan 2014 10:02:25 -0800 (PST)
Links: << >>  << T >>  << A >>
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.
> 
> 
> 
> Robert

Article: 156170
Subject: Re: register naming
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 6 Jan 2014 18:53:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
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,

Mark


Article: 156171
Subject: Re: register naming
From: "mnentwig" <24789@embeddedrelated>
Date: Mon, 06 Jan 2014 15:13:44 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 156172
Subject: Re: register naming
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 6 Jan 2014 22:10:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen



Article: 156173
Subject: Re: register naming
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 6 Jan 2014 22:39:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
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,

Mark



Article: 156174
Subject: Re: register naming
From: "mnentwig" <24789@embeddedrelated>
Date: Mon, 06 Jan 2014 17:28:46 -0600
Links: << >>  << T >>  << A >>
>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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search