Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Strange behavior of Altera FIFO

Status
Not open for further replies.

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,300
Hello,

Using Active HDL - I've been simulating a synchronous FIFO created by Altera's IP Catalog.

This is the instantiation of the FIFO:

Code:
LIBRARY ieee;
USE ieee.std_logic_1164.all;

LIBRARY altera_mf;
USE altera_mf.all;

ENTITY altera_fifo IS
	PORT
	(
		clock		: IN STD_LOGIC ;
		data		: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
		rdreq		: IN STD_LOGIC ;
		wrreq		: IN STD_LOGIC ;
		empty		: OUT STD_LOGIC ;
		full		: OUT STD_LOGIC ;
		q		: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
		usedw		: OUT STD_LOGIC_VECTOR (3 DOWNTO 0)
	);
END altera_fifo;


ARCHITECTURE SYN OF altera_fifo IS

	SIGNAL sub_wire0	: STD_LOGIC ;
	SIGNAL sub_wire1	: STD_LOGIC ;
	SIGNAL sub_wire2	: STD_LOGIC_VECTOR (7 DOWNTO 0);
	SIGNAL sub_wire3	: STD_LOGIC_VECTOR (3 DOWNTO 0);



	COMPONENT scfifo
	GENERIC (
		add_ram_output_register		: STRING;
		intended_device_family		: STRING;
		lpm_numwords		: NATURAL;
		lpm_showahead		: STRING;
		lpm_type		: STRING;
		lpm_width		: NATURAL;
		lpm_widthu		: NATURAL;
		overflow_checking		: STRING;
		underflow_checking		: STRING;
		use_eab		: STRING
	);
	PORT (
			clock	: IN STD_LOGIC ;
			data	: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
			rdreq	: IN STD_LOGIC ;
			wrreq	: IN STD_LOGIC ;
			empty	: OUT STD_LOGIC ;
			full	: OUT STD_LOGIC ;
			q	: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
			usedw	: OUT STD_LOGIC_VECTOR (3 DOWNTO 0)
	);
	END COMPONENT;

BEGIN
	empty    <= sub_wire0;
	full    <= sub_wire1;
	q    <= sub_wire2(7 DOWNTO 0);
	usedw    <= sub_wire3(3 DOWNTO 0);

	scfifo_component : scfifo
	GENERIC MAP (
		add_ram_output_register => "ON",
		intended_device_family => "Stratix V",
		lpm_numwords => 16,
		lpm_showahead => "OFF",
		lpm_type => "scfifo",
		lpm_width => 8,
		lpm_widthu => 4,
		overflow_checking => "ON",
		underflow_checking => "ON",
		use_eab => "ON"
	)
	PORT MAP (
		clock => clock,
		data => data,
		rdreq => rdreq,
		wrreq => wrreq,
		empty => sub_wire0,
		full => sub_wire1,
		q => sub_wire2,
		usedw => sub_wire3
	);



END SYN;

I simulated the design by applying stimuli to clock , wrreq and rdreq.
When wrreq = '1' - "usedw" and "empty" get updated on the rising egdge as expected. However, the actual content of the FIFO's memory matrix gets updated only on the falling edge of the clock...

Why is that?
Please review the attached waveform.
 

Attachments

  • Untitled.png
    Untitled.png
    12.5 KB · Views: 12

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
Because thats how their memory model works. What you're simulating is not the chip, its an HDL model - doing updates on the falling edge is a way to understand the waves a little better
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,300
doing updates on the falling edge is a way to understand the waves a little better
Yet they find fit to update the control flags on the rising edge - Why the difference??
 

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,820
Helped
1,811
Reputation
3,632
Reaction score
1,772
Trophy points
1,393
Location
USA
Activity points
59,033
Shaiko,

More likely the model was written by some junior engineer or new grad.

e.g. Xilinx used to have an ODDR model that was written like an ASIC ODDR model. There wasn't any kind of # delays (Verilog) in the code and it worked great. Some where between the 9.x version and 10.x version of the Xilinx tools they replaced the model with a new (improved?) model that looked like it was written by a new grad. # delays were strew all over the model and the only way to make it work in your design was to add something like a #5 delay to the data inputs of the ODDR in your synthesizable RTL to compensate for the stacked delays in the model! Needless to say I never complied the new ODDR model I always used the old one, which was written correctly.

I originally discovered this, because my design didn't work the same way in hardware as it did in the simulation. When I added # delays to the ODDR data inputs then the simulation matched the hardware. The thing was I'd used the ODDR registers before in designs so I was wondering why the hardware behaved the same as the simulation previously, that's when I discovered they changed the Verilog simulation models for the ODDR.

I did ask an FAE once about this and they said use the old model.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,300
Another strange behavior I encountered...

I set the FIFO as "show-ahead".
And disabled the RAM output register.
It seems like the above has no effect - the output still comes registered ( Written data appears at the output a full clock after the write operation )

This is the FIFO's instantiation:

Code:
	scfifo_component : scfifo
	GENERIC MAP (
		add_ram_output_register => "OFF",
		intended_device_family => "Cyclone IV E",
		lpm_numwords => 256,
		lpm_showahead => "ON",
		lpm_type => "scfifo",
		lpm_width => 8,
		lpm_widthu => 8,
		overflow_checking => "ON",
		underflow_checking => "ON",
		use_eab => "ON"
	)
	PORT MAP (
		clock => clock,
		data => data,
		rdreq => rdreq,
		wrreq => wrreq,
		empty => sub_wire0,
		full => sub_wire1,
		q => sub_wire2,
		usedw => sub_wire3
	);

The waveform is attached.
View attachment 118992
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
This is a FIFO - so why do you care?
Look-ahead just means that the q output is aligned with empty.
In non-lookahead mode, the data is valid 1 clock after not empty and rdreq.

In my mind, how the model works internally is immaterial, aslong as the interface behaves as expected.
 

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,300
In my mind, how the model works internally is immaterial
It isn't just about the model - it's about the setting not taking effect ( add_ram_output_register => "OFF" ).

aslong as the interface behaves as expected.
It doesn't...
The FIFO's RAM is configured to have a non-registered output. Yet the output comes out registered regardless of the configuration in place.
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
It isn't just about the model - it's about the setting not taking effect ( add_ram_output_register => "OFF" ).


It doesn't...
The FIFO's RAM is configured to have a non-registered output. Yet the output comes out registered regardless of the configuration in place.

You're using a FIFO - it has extra logic around a ram. No data is valid until empty = '0'. The RAM behaviour is nothing to do with the FIFO.
If you want the ram - instantiate the ram - it will behave correctly.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,820
Helped
1,811
Reputation
3,632
Reaction score
1,772
Trophy points
1,393
Location
USA
Activity points
59,033
Are you changing the altera_fifo.vhd code you posted in #1, by manually changing add_ram_output_register => "ON" to add_ram_output_register => "OFF"?

If so, that is likely why the behavior doesn't change.

If you want to change the behavior of the FIFO you have to change the settings when generating the core as the megafunction wizard will change the underlying simulation code depending on what features you request.
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
Are you changing the altera_fifo.vhd code you posted in #1, by manually changing add_ram_output_register => "ON" to add_ram_output_register => "OFF"?

If so, that is likely why the behavior doesn't change.

If you want to change the behavior of the FIFO you have to change the settings when generating the core as the megafunction wizard will change the underlying simulation code depending on what features you request.

Altera cores just create a wrapper to a VHDL library. So modifying the generated wrapper should modify the setup. It means you can easily bypass the wizard and just instantiate these things yourself, unlike the Xilinx controlling philosphy of forcing you to use the coregen.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,820
Helped
1,811
Reputation
3,632
Reaction score
1,772
Trophy points
1,393
Location
USA
Activity points
59,033
Altera cores just create a wrapper to a VHDL library. So modifying the generated wrapper should modify the setup. It means you can easily bypass the wizard and just instantiate these things yourself, unlike the Xilinx controlling philosphy of forcing you to use the coregen.

So I guess that means Altera doesn't auto-generate code using perl scripts in the background, All the simulation code then exists with all the options controlled by the generics?
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
So I guess that means Altera doesn't auto-generate code using perl scripts in the background, All the simulation code then exists with all the options controlled by the generics?

Yes - you can even browse the source code for all of the altera_mf library (its 10s of thousands of lines in 1 file!)
 

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,300
Are you changing the altera_fifo.vhd code you posted in #1, by manually changing add_ram_output_register => "ON" to add_ram_output_register => "OFF"?
Yes,
But TrickyDicky is right, changing the upper hierarchy's generics does effect to the lower hierarchies (without regenerating the core through the wizard).
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,065
Helped
2,077
Reputation
4,171
Reaction score
2,030
Trophy points
1,393
Activity points
39,119
Yes - you can even browse the source code for all of the altera_mf library (its 10s of thousands of lines in 1 file!)

At least you used to be able to
It might be when I had modelsim_altera installed - I would just recompile the code when I hit a new modelsim version.
 

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,820
Helped
1,811
Reputation
3,632
Reaction score
1,772
Trophy points
1,393
Location
USA
Activity points
59,033
Well that is definitely different than what Xilinx does, they typically auto-generate with perl scripts the code used for the design parameters specified, hence they always have warnings about unconnected stuff (unused wires/signals) in their auto-generated files.

I don't think this has anything to do with being "controlling". It's just a different way of approaching the problem of creating IP with multiple options. Either have an enormous piece of code that has every option under the sun with huge ifdef or generate-ifs to decide what options take effect (Altera's method) or write a script that generates the code for the options specified (Xilinx's method). Regardless, which way you go they both have the same results, you can create user modifiable IP.

Regardless whether or not you can hand edit, I normally never hand edit anything that is tool generated, too much of a chance for some clod down the line to regenerate the core, breaking the design. I suppose this would work if the wrapper file is the file that the IP uses to generate the core (is this the case with Altera?).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top