A simple 3:8 decoder

Status
Not open for further replies.
Sorry, i was wrong in explanation, i mean to say assigning outputs.. which K-J corrected

I was asking about following conditions:

CONDITION 1:

Entity
{
//inputs
//outputs
}
architecture
{
//assigning all outputs to initial value
}

CONDITION 2:

Entity
{
//inputs
//outputs
}
architecture
{
//nothing assigned to outputs and architecture section is blank
}

I was of the view that, condition 1 creates a latch to hold outputs, where as condition 2 doesn't create any logical schematic.
 

Neither produces latches. They both just drive the outputs to a constant value.
For 1 the constant you defined. 2 will be chosen by the compiler (pronably affected by your compile settings).
 
Why should "condition 1" use latches? It also infers outputs wired to fixed logic levels, as "condition 2".

Presuming the output have std_logic type, "condition 2" creates a simulation mismatch. Uninitialized std_logic is set to 'U' state in functional simulation. In synthesized hardware, they are ususally set to '0'.
 
embeddedlover said:
Sorry, i was wrong in explanation, i mean to say assigning outputs.. which K-J corrected

<snip>
I was of the view that, condition 1 creates a latch to hold outputs, where as condition 2 doesn't create any logical schematic.
Click to expand...

Hopefully you were only of that view before reading my last post and not afterwards. I explained both conditions in that post...so what exactly are you asking now?

Kevin Jennings
 

Why should "condition 1" use latches? It also infers outputs wired to fixed logic levels, as "condition 2".
Click to expand...

I was thinking that, when a output is assigned a value, instead of a fixed wired connection, a latch will be created to hold that value until power if off..

Presuming the output have std_logic type, "condition 2" creates a simulation mismatch. Uninitialized std_logic is set to 'U' state in functional simulation. In synthesized hardware, they are ususally set to '0'.
Click to expand...

simulation mismatch mean?
Are there any other logic types, other than std_logic?

Hopefully you were only of that view before reading my last post and not afterwards. I explained both conditions in that post...so what exactly are you asking now?
Click to expand...

Ya, it was true that i was thinking that in terms of input.. because only when we assign inputs, we get outputs.. in that view i was asking.. but in logic, we do write assigning outputs.. finally, my question there was.. logic diagram with and without values assigned..
 

embeddedlover said:
I was thinking that, when a output is assigned a value, instead of a fixed wired connection, a latch will be created to hold that value until power if off..
Click to expand...

You thought wrong

simulation mismatch mean?
Are there any other logic types, other than std_logic?
Click to expand...

No, but std_logic has 6 states that you will not see on real hardware. Real hardware can only output '1', '0' or 'Z'. But std logic also has 'U' (uninitialised), 'X' (unknown), '-' (dont care), 'H' (weak high),, 'L' (weak low), 'W' (weak unknown). So if you leave it without a specific value the simulation will show 'U', but when compiled and you looked on a logic analyser, you would probably see '0'.
 
In a micro controller, to state on the output pins is nothing but the one written onto the corresponding interface register.. Whether it is serial or parallel or a simple GPIO interface.. Here registers are nothing but latches..

So, i was linking the same to FPGA here.. My opinion was that digital logic is same everywhere.. So, to put onto a FPGA pin, isn't a register (latch) required?
 

No, it can connect the logic level directly to the pin. There is a register there but it's not needed. I suggest you read the documentation for your device.
 
But for information considering the same psuedo code, when does a latch gets created?

Also, wanted to know if there is any error in the following code:

entity counter1 is
Port ( CLK : in STD_LOGIC;
COUNTER : out STD_LOGIC_VECTOR (2 downto 0));
end counter1;

architecture Behavioral of counter1 is

begin
process(CLK)
variable COUNT:unsigned(2 downto 0) := "000";
begin
if(CLK'EVENT and CLK = '1') then
COUNT := COUNT + 1;
end if;

if(COUNT > 6) then
COUNT := "000";
end if;
COUNTER <= COUNT;
end process;
end Behavioral;
 

Well, no error. but it doesnt follow a proper template, as your code is not inside the clocked part of the process. It may create a transparent latch for the counter output, and you'll get missmatch between the simulation and syntheis is that happens.
 
ERROR:HDLParsers:800 - "E:/xilinxprogs/counter/counter1.vhd" Line 51. Type of COUNTER is incompatible with type of COUNT.
Click to expand...

It throws me above error during synthesis..
 

Yes, you need to convert the unsigned count to a std_logic_vector

counter <= std_logic_vector(count);

But why are you not simulating the design first?
 
Thank you trickydicky, that worked..

As "Check syntax" is also part of that synthesize-XST, just doing that..

- - - Updated - - -

I have few more questions,

1. Under which logic does the synthesize lead me to create LATCHES? You guys were previously mentioning that, this code will create will create latches.
2. If i want to test my code on board, it seems, the JTAG tool chain is too expensive to buy.. any low cost solutions? Like for micro controller have ISP..
3. what is the low cost evaluation board available in market?
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…