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 83450

Article: 83450
Subject: Re: how can I improve my code?
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Sat, 30 Apr 2005 02:24:21 +0200
Links: << >>  << T >>  << A >>
Hi Bert,

thanks for looking at the code.

> I suggest you could start with :

> process 1 : missing reset on lvds_clk

what do you mean by that? should I set lvds_clk to '0' during reset?

> process 2 : you use both edges of the clock ? (do you need this ?)

I think I need both edges, because there is no pause between two bytes, 
so the shift register needs to be loaded with the new data between the 
last and first bit. Or is there a better way (probably...)?

> process 3 : wrong sensitivity list, maybe not synthesizable
>    depending on the target technology (asynchronous load),
>    lvds_1_in is clocked by both edges and negatively clock enabled
>    load_lvds ??

I have changed this process...

I have my new code attached. However I have read that case statements 
are better, because they can be implemented parallel... I will change that.

I have put the two processes that do the lvds_clk and the pixel counting 
into one process. Is it generally better to have one big process?

regards,
Benjamin


-- lvds_tick is a clock at 7x pixel-clock	(140 MHz)
-- lvds_clk is the clock for the lvds bus, same as pixel clock, but not 
symmetric
-- like this for one pixel period: --___--
process (lvds_tick,screen_reset)
begin
	if screen_reset='1' then
		lvds_div<=0;
		row_count <= 0;
		col_count <= 0;
		DTMG <= '1';
		VSYNC <= '0';
		HSYNC <= '0';
	elsif rising_edge(lvds_tick) then
		if lvds_div = 0 then
			lvds_clk <='1';
		elsif lvds_div = 2 then
			lvds_clk<='0';
		elsif lvds_div = 5 then
			lvds_clk<='1';
		end if;
		
		if lvds_div = 6 then
			lvds_div <= 0;

			------------
			
			if col_count = 1023 then
				DTMG <= '0';
				HSYNC <= '1';
			elsif col_count = 1035 then
				HSYNC <= '0';
			end if;
		
			if col_count = 1075 then
				col_count <= 0;
				if row_count < 767 then
					DTMG<='1';			
				elsif row_count = 767 then
					VSYNC <= '1';
				elsif row_count = 769 then
					VSYNC <= '0';
				end if;
				if row_count = 783 then
					row_count <= 0;				
					DTMG<='1';
				else
					row_count <= row_count +1; 			
				end if;

			else
				col_count <= col_count +1;
			end if;			

			-------------

		else
			lvds_div <= lvds_div + 1;
		end if;

	end if;	
end process;

-- this process generates the load impuls for the shift register below
process (lvds_tick,screen_reset)
begin
	if screen_reset='1' then
		load_lvds<='1';
	elsif falling_edge(lvds_tick) then
		if lvds_div = 0 then
			load_lvds<='1';
		else
			load_lvds<='0';
		end if;
	end if;
end process;

-- generates serial data for one lvds-pair
lvds_1:process (lvds_tick)
begin
    if rising_edge(lvds_tick) then
		if load_lvds='1' then
			reg1 <= lvds1;
		else	
       	reg1 <= reg1((5) downto 0) & '0';
		end if;
    end if;
    lvds_1_in <= reg1(6);
end process;

Article: 83451
Subject: Re: signals in modelsim
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Sat, 30 Apr 2005 03:13:47 +0200
Links: << >>  << T >>  << A >>
Hi,

simulating behavior doesnt work. Modelsim gives me this:

# ** Error: (vsim-3170) Could not find 'work.uut'.
# Error loading design
# Error: Error loading design

with exactly the same configuration, simulating Post-Translate, Post-Map 
and Post-Place all work. My testbench is instantiated as uut.

regards,
Benjamin

Article: 83452
Subject: Re: signals in modelsim
From: =?ISO-8859-1?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Sat, 30 Apr 2005 03:15:14 +0200
Links: << >>  << T >>  << A >>
Hi Gallen,

it helped.

regards,
Benjamin

Article: 83453
Subject: Re: How to implement this C function in FPGA
From: "JJ" <johnjakson@yahoo.com>
Date: 29 Apr 2005 19:27:03 -0700
Links: << >>  << T >>  << A >>
Stanley

Since you are not going to or are not able to disclose any details
about the project, you probably won't get any real help here, I think I
understand your situation. You only got a response because of your tsmc
address.

Its a shame you didn't post 2 months ago, I was in Hsinchu for some
time, I could of just walked in signed the NDA and worked out a
consultancy deal for you and given you a few months of my time. My wife
certainly wouldn't have minded staying longer.

I and many others here are used to working on wierd and or interesting
problems for US/EU hourly rates though.

As a former customer of TSMC foundry services on a wavelet chip that
also turned some neat FP math into integer ASIC, I understand that your
group might not want the world to have a clue what you might be up to
after all you are supposed to be a pure play foundry. This project does
not fit what I usually see designed in Taiwan (thinking mobo,
networking, controllers, consumer etc).

You can write me or any of the regular consultants here if you want
some serious help.

regards

johnjakson at usa dot com
508 480 0777


Article: 83454
Subject: Re: Map Error: "RLOC not supported for simple gates"
From: Jim George <send_no_spam_to_jimgeorge@gmail.com>
Date: Fri, 29 Apr 2005 22:15:58 -0600
Links: << >>  << T >>  << A >>

> The problem with attaching RLOC to a gate, even if the gate is
> instantiated rather than inferred, is that the mapper will not
> necessarily keep the gate by itself in the final design.  Usually
> several gates can be lumped into a single LUT.  The tools might
> have allowed an RLOC constraint on gates that don't get grouped
> together, but unfortunately they don't.  If you have a combinatorial
> function that needs to end up with a particular placement, the
> only way is to instantiate a LUT instead of gates or gate primitives.
> 
> Instantiated flip-flops don't have this problem.
> 

OK... thanks. I guess Xilinx has their reasons.

Article: 83455
Subject: Re: crazy behaviour of fpga, timing ?
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 30 Apr 2005 09:27:20 +0200
Links: << >>  << T >>  << A >>
Alexander Korff wrote:
> Hi,
> 
> after I added an extra process which gets the data (without combinational 
> logic) from the external device, everything worls fine (-:
> Thanks very much!
> 
> Alex

Thanks for the feedback.
Apparently complex problems often have simple solutions :-)

But remember that, if your input are synchronous to a clock that
you are using in the FPGA, you should define the constraints.
Dependending on Frequency, your design usually has very high
chances to "work" just by registering the I/Os in or near the
IO cell, but that is not totally reliable... a change of speed
grade, or a new batch of components may alter this.
With proper constraints, it _will_ work, or you'll be warned
by STA.


Bert Cuzeau

Article: 83456
Subject: Case statement illusions ?
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 30 Apr 2005 11:24:26 +0200
Links: << >>  << T >>  << A >>
Symon wrote:
> 
> ...and learn about 'case' statements.
> Syms.
> 

I take advantage of your post (and of the WeekEnd)
for a question to the group.

I often see newbies writing things like :

case my_std_logic is
   when '0' =>
   when '1' =>
   when others =>    -- they HAVE to write this indeed !!
end case;

They seem to believe it would be a better (more efficient !)
style than :
  if my_std_logic='1' then
  else
  end if;

?????
Since I've seen this a number of times, I'm curious
to know who is telling them this ? and why ? a book ?

And when things get more complex, even more people seem
to say that the case statement is a miracle... and
would magically turn a "serial" computation into a "parallel"
one, more efficient, that one has a priority while the other
would not etc etc.... I usually hear the very same persons
say they don't know what the '-' (don't care) is about !

I'm _not_ saying here that the case statement is never to
be preferred, but the designer must be aware of the reality.
The case statement in VHDL also has it's unfriendly sides
(you often have to qualify the case expression like in
"case A&B is" + there is also the locally static issue
+ no way to use std_match in a case + case must be complete, etc...).
The Verilog case statement, associated with parallel case
pragma, is more versatile (like with a constant selector).

Even using the case statement (and don't cares), obtaining
the minimal logic sometimes requires efforts (as for the one
hot minimal decoder).
My recommendation is to usually favor the style which provides
the best expressiveness even at the (hypothetical) cost of a
few gates.

I quickly wrote the example below.
Note that I didn't merge the cases or the ifs so different
decoding logic can easily be tested. It is also possible
to remove some case(s) (thanks to the default statements).

Has anyone different views or experience to share ?

---------------------------------------------------------
-- Will the "case" statement really change your life :-) ?
--
-- Please let me know if there is one synthesis tool which
-- does provide a different QOR for the two architectures below.
-- I would use the case statement myself, but not in the
-- hope of better QOR.

library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.numeric_std.all;

Entity casetest is
   port ( A : in  std_logic_vector (3 downto 0);
          Q : out std_logic_vector (3 downto 0)   -- MSB not used (= 0)
        );
end;

-- ------------------------------------
architecture RTL_case of casetest is

begin

process (A)
begin
   case A is
     when x"0" =>
       Q <= x"0";
     when x"1" =>
       Q <= x"1";
     when x"2" =>
       Q <= x"2";
     when x"3" =>
       Q <= x"2";
     when x"4" =>
       Q <= x"3";
     when x"5" =>
       Q <= x"3";
     when x"6" =>
       Q <= x"3";
     when x"7" =>
       Q <= x"3";
     when x"8" => -- could use when others here
       Q <= x"4";
     when x"9" =>
       Q <= x"4";
     when x"A" =>
       Q <= x"4";
     when x"B" =>
       Q <= x"4";
     when x"C" =>
       Q <= x"4";
     when x"D" =>
       Q <= x"4";
     when x"E" =>
       Q <= x"4";
     when x"F" =>
       Q <= x"4";
     when others =>
       Q <= "----";
   end case;
end process;

end architecture RTL_case;

-- --------------------------------------------
architecture RTL_if of casetest is

begin

process (A)
begin
   if A = x"0" then
     Q <= x"0";
   elsif A = x"1" then
     Q <= x"1";
   elsif A = x"2" then
     Q <= x"2";
   elsif A = x"3" then
     Q <= x"2";
   elsif A = x"4" then
     Q <= x"3";
   elsif A = x"5" then
     Q <= x"3";
   elsif A = x"6" then
     Q <= x"3";
   elsif A = x"7" then
     Q <= x"3";
   elsif A = x"8" then  -- could put an "else" here
     Q <= x"4";
   elsif A = x"9" then
     Q <= x"4";
   elsif A = x"A" then
     Q <= x"4";
   elsif A = x"B" then
     Q <= x"4";
   elsif A = x"C" then
     Q <= x"4";
   elsif A = x"D" then
     Q <= x"4";
   elsif A = x"E" then
     Q <= x"4";
   elsif A = x"F" then
     Q <= x"4";
   else
     Q <= "----";
   end if;
end process;

end architecture RTL_if;


Article: 83457
Subject: Re: Flexray ip core
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 30 Apr 2005 12:00:16 +0200
Links: << >>  << T >>  << A >>
>
> I'm looking for a Flexray IP core: Commercial or OpenSource project
>
> Flexray is a time triggered bus that aims to be the backbone of in car networks (CAN, LIN, MOST...).
>
> I'm just trying to find some source to implement a Flexray controller in a FPGA (eg: Spartan II) for educational purpose, just 
> waiting for commercial Flexray controllers to be produced.
>
>
> Does somebody have heard about that?
>


Try to contact http://www.decomsys.com/

They developed the controller for Motorola and also have an FPGA version
(e.g Cyclone).
I worked for them and did part of the Flexray controller.

Martin



Article: 83458
Subject: using cadence tool
From: madhav1111@gmail.com
Date: 30 Apr 2005 03:43:27 -0700
Links: << >>  << T >>  << A >>
hi,
  I have a problem in using the Silicon Ensemble (place and route). I
am getting the following error while loading .LEF files.

** EXCHANGEFORMATS-USER-113  ERROR **
Cannot create database because:
db lock create failed, conflicting lock file is : LBRARY.dtp ONE WRITE
ACCESS allowed:.
** CADENCE-USER-53  WARNING **
Input source will abort at next read due to limit of 1 PROBLEMs.

Can anyone get me out of this problem.
Thanx in advance,
Madhav


Article: 83459
Subject: Re: Case statement illusions ?
From: =?ISO-8859-1?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Sat, 30 Apr 2005 12:57:39 +0200
Links: << >>  << T >>  << A >>
Hi Info,

I have read here, that case is more parallel:

http://www.vhdl-online.de/tutorial/deutsch/t_201.htm

regards,
Benjamin

Article: 83460
Subject: Re: Case statement illusions ?
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 30 Apr 2005 13:47:50 +0200
Links: << >>  << T >>  << A >>
Benjamin Menküc wrote:
> Hi Info,
> 
> I have read here, that case is more parallel:
> 
> http://www.vhdl-online.de/tutorial/deutsch/t_201.htm
> 
> regards,
> Benjamin

I became the Saint Thomas of RTL syntyhesis :-)

So let's take the example from your University course.
-ich verstehe ein bischen Deutsch-
I just modified the names to avoid reserved keywords
and added the proper types :

-- "case" statement tests
-- Bert Cuzeau

library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.numeric_std.all;

Entity casetest2 is
   port ( A,B,C,Ad : in  std_logic_vector (4 downto 0);
          Q        : out std_logic_vector (4 downto 0)
        );
end;

-- --------------------------------------------

architecture RTL_if of casetest2 is
-- 12 LEs

begin

process (Ad,A,B,C)
begin
   if unsigned(Ad) > 17 then
     Q <= A ;
   elsif unsigned(Ad) < 17 then
     Q <= B ;
   else
     Q <=  C ;
   end if ;
end process;
end architecture RTL_if;

-- ------------------------------------

architecture RTL_case of casetest2 is
-- 12 LEs ?!

begin

process (Ad,A,B,C)
begin
   case to_integer(unsigned(Ad)) is
     when 0 to 16 =>
          Q <= B ;
     when 17 =>
          Q <= C ;
     when others =>
          Q <= A ;
   end case;
end process;

end architecture RTL_case;

Both RTL views "look" different indeed, but...
both styles end up with exactly the same number of LEs !
(used Quartus II's internal synthesis)
and identical timing performance.
With XST (ISE 6.3.03), the case version is 7 slices vs 6 slices for
the "if" version. We may hope it's slightly faster, but I wouldn't
bet on that either.

So I still don't see any proof that the case statement is the
(only) way to go.

But I am _not_ saying that arithmetic operator inference is
something not to care about !!! Quite the contrary !
With larger operators, I would double check, consider using
only one magnitude comparator, etc... (given a _strong_ motivation
for area or timing perf, otherwise I wouldn't care much and I
would spend my time more productively).

It's just that "coding style QOR" is a more complex issue than
it may seem, and is often very tool-dependant.
Even with a given tool, optimization options may impact the QOR.

...and I believe what I see by myself, and I always verify the big
"we are the best" statements from the tools vendors ;-)

Bert Cuzeau

Article: 83461
Subject: Re: Case statement illusions ?
From: "Mohammed A khader" <am.imak@gmail.com>
Date: 30 Apr 2005 04:59:15 -0700
Links: << >>  << T >>  << A >>
HI Bert,

  Intersting topic to talk about ! .

>  I often see newbies writing things like :
 >  [Snipped]..............
> ?????  Since I've seen this a number of times, I'm curious
> to know who is telling them this ? and why ? a book ?

  I am a newbie(still at academic level) but I'll not accept from a
book without saying why.
> to know who is telling them this ?
  Here is the list which I have read  .....
 1) RTL Implementaion Guide   by Jack Marshall (from tera systems Inc).
( I got this from synopsys SNUG group,check it if u have account )
2) Coding style from synopsys
 3)
http://www.utdallas.edu/~shankars/teaching/ee5325/foils/lectures/lecture17.pdf
 (Slid number 17)

 4) http://min.ecn.purdue.edu/~ee495d/Lectures/synthesis.pdf

 All say that case  infers a  parallel logic and if-elsif-else  infers
a proirity encoder structure ...  If  situation does'nt demand me for a
prority logic Why shall I  choose it ???

> The case statement in VHDL also has it's unfriendly sides
> (you often have to qualify the case expression like in
> "case A&B is" + there is also the locally static issue
> + no way to use std_match in a case + case must be complete, etc...).


problem of qulifying expression has been addressed  by vhdl committee
and it is going be fixed soon.

completness of case is an advantage to find the bugs.Lets take an
example....
 Take the exmaple you mentioned above

> case my_std_logic is
>   when '0' =>
>   when '1' =>
>   when others =>    -- they HAVE to write this indeed !!
> end case;


>They seem to believe it would be a better (more efficient !)
>style than :
>  if my_std_logic='1' then
>  else
>  end if;

  Suppose  my_std_logic is a conrol signal which must be initialized
properly after reset. I cannot see that with your if - else code . but
by having others clause  I could watch all uninitialized 'U' signals by
case statement.

> Even using the case statement (and don't cares), obtaining
> the minimal logic sometimes requires efforts (as for the one
> hot minimal decoder).
 I dont know partiuclarly about one hot minimal decoder but
 Synthesis tools say case statments are good for area opptimizations.

>My recommendation is to usually favor the style which provides
>the best expressiveness even at the (hypothetical) cost of a
>few gates.
 I dont think  if-else provide more  " expressiveness " then case. For
parallel code case is more "expressiveness".
 At the end  merits of hardware counts wheather  it is in the form of
few gates. Dont under estimate the  number of gates as it is know
causing more static power.

 > Has anyone different views or experience to share ?

 Thank you very much for starting such an interesting topic.
 

 -- Mohammed A Khader.


Article: 83462
Subject: Re: Case statement illusions ?
From: =?ISO-8859-1?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Sat, 30 Apr 2005 14:04:14 +0200
Links: << >>  << T >>  << A >>
Hi,

it would be interesting to know, if the if-style gets worse compared to 
the case-style, when we have a very long if-chain (10x elsif or so).

regards,
Benjamin

Article: 83463
Subject: problems getting flex10k10 to work
From: "LENNART KIRKEVIK" <lennart.kirkevik@online.no>
Date: Sat, 30 Apr 2005 15:56:39 +0200
Links: << >>  << T >>  << A >>
I have a flex10k10lc84-4 and have just bulit a test circuit for it. I am 
using the MAX+plusII software.  I made a simple AND port and compiled and 
programmed it with a byteblaster II cable. I got no error messages, just the 
"configuration complete". When testing, the output was low regardless of the 
state of the inputs. The flex 10k10 seems to be dead except when programming 
it.

Does someone have an idea ?

Lennart Kirkevik



Article: 83464
Subject: VGA sync signals
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Sat, 30 Apr 2005 16:02:52 GMT
Links: << >>  << T >>  << A >>
I'm doing a VGA sync generator in a Virtex II and can't decide how to go 
about driving the HS and VS signals to the connector. Does anyone have any 
experience / ideas about this that would be helpful please? Presumably I 
could:

1) Simply drive the signals from the FPGA (LVTTL signal level) and not worry 
about it.
2) As above but put some protection diodes on the lines.
3) Put series resistors in the signals (I've seen this on an old FPGA 
board).
4) Use a buffer chip e.g. LS07.

TIA Rog. 



Article: 83465
Subject: Re: Downloading problems [Memec DS-BD-V2MB1000 Virtex-II board].
From: Henrik Koksby Hansen <news@k0ksby.dk>
Date: Sat, 30 Apr 2005 18:24:03 +0200
Links: << >>  << T >>  << A >>
>I am using JTAG Cable IJC-2 from Memec and Xilinx Platform Studio
>(Xilinx EDK 6.3 Build EDK_Gmm.12.3+1) to program subj.
>
>Typically in the morning, the programming fails constantly until it
>suddenly works after an hour or two. When it then works, it keeps
>working. For that reason i beleive my code is OK. ;-)
>
>When it does not work, i get this error:
>
>  ---
>  INFO:iMPACT:580 - '2':Checking done pin ....done.
>  '2': Programming terminated, Done did not go high.
>  Elapsed time =     21 sec.
>  ---
[...]

The solution was to NOT connect the Vcc-wire of the JTAG to the JTAG
interface on the board - but directly to the 3,3V supply outlet on the
board. Well, it didn't solve the problem completely, but it is much
much better now.



-- 
Henrik

Article: 83466
Subject: Re: VGA sync signals
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 30 Apr 2005 18:24:19 +0200
Links: << >>  << T >>  << A >>

"Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag
news:M_Nce.8045$_s1.3328@newsfe6-gui.ntli.net...

> 1) Simply drive the signals from the FPGA (LVTTL signal level) and not
worry
> about it.
> 2) As above but put some protection diodes on the lines.
> 3) Put series resistors in the signals (I've seen this on an old FPGA
> board).

Use series resistors of about 50 ohms. this will give you roughly 75 Ohms
output impedance, well matched to the cable.

Regards
Falk




Article: 83467
Subject: Re: Case statement illusions ?
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 30 Apr 2005 18:25:38 +0200
Links: << >>  << T >>  << A >>
Just a few extra comments :

Mohammed A khader wrote:
>  All say that case  infers a  parallel logic and if-elsif-else  infers
> a proirity encoder structure ...  

They don't quite say this (or they'd lie).
"If ... elseif" has an implied priority (first test true -> next tests
are not taken)... but that makes no sense when you describe a truth table !
(as in my first encoder example)
Whatever the means to describe behaviorally the truth table, it
will end up the same, and by way of logic reduction it will lead
to implementations that may or may not be similar depending
on synthesis tools optimization goals, constraints, internal
logic reduction algorithm, etc...
Things may become different when complex operators are inferred.
The BIG difference is that, from a synthesis perspective,
describing a truth table isn't the same as describing higher
level structures !

What I mean is be wary of general rules about synthesis. There are more
than one tool, and tens of years of research behind them...
I think it's pretty dangerous to say "this does infer that".
Or you have to be damn accurate : given code snippet, given tool,
given version, given technology, given constraints, etc etc

> problem of qulifying expression has been addressed  by vhdl committee
> and it is going be fixed soon.

1. I didn't mean it was a problem ! You just need to know the language.
   Qualified expressions are just often unknown to newbies, but they
   are extremely useful. write (L,"hello"); for example.
   There's no problem in writing "case A&B" (a qualified expr does it).
   It's also possible to get directly the two MSBs of A + B (vectors).
   One just needs to know a bit more than the basics of VHDL.

2. What do you mean by "has been addressed..."? I don't want to start
  another controversy, but VHDL200X isn't out of the woods.
  We all just hope it will happen (out of IEEE and then into our tools)
  before the EDA community majority has switched to SystemVerilog.
  But there is absolutely no real need of a better VHDL for simple designs.

> completness of case is an advantage to find the bugs.Lets take an
> example....

It's MUCH easier to follow good coding rules which ensure that the
bad situation you mention will never happen in your design that
trying to test every signal again 'U' !
If you want to do this, be consistent and write a test for every
numeric vector, making sure it doesn't include any 'U'. Not cool.

Simple gross mistakes are easier to prevent than to detect.

I think this is the same with std_ulogic, which use was supposed
to help detect multiple drivers situations (it did). But there
are other ways to check this and so many other bad things are
to be tested at synthesis that everybody has dropped now this
unresolved type and obsolete style.

>  I dont know partiuclarly about one hot minimal decoder but
>  Synthesis tools say case statments are good for area opptimizations.

It's called hearsay I think.
Then, why doesn't it show up in the simple examples I gave ?
(XST 6.3.03i creates in fact a larger design with the "case" version)

I have reproduced below an old example that I sometimes used
in my courses. I kept it simple minded (no fancy function).
Why don't all synthesis tools give the simple OR gates ?
- The case version "looks" nicer, but check the gates count (with your tool).
- In the "if" solution : do you see a priority after synthesis ??
Chances are your synthesis tool will produce three times larger solution
with the case than with the if.
Don't believe ppt slides (nor me) !

> Dont under estimate the  number of gates as it is know
> causing more static power.

0. How do you know you have "saved" some gates and achieved
  and an optimal solution ? What do you compare against ?
  In the example below, was 15 LUTs acceptable or not ? (without
  the comments saying it was not).

1. The case doesn't always produce less gates, sometimes
  the contrary as proved here.
  I try to not underestimate anything ! I just check by myself
  as much as I can and I encourage you, if you're sensitive to gate
  count and QOR, to always verify and never simply "assume".

2. If design could be made significantly smaller by avoiding "ifs",
  then don't you think the Synthesis tools would automatically do
  the translation internally ? (they do, this and many other tricks)

3. There is one or two orders of magnitude higher potential gain
  by smart implementation and good design know-how :
  being a smart architect pays !

4. Most synthesis tools are smarter and smarter, so a good
  understanding of your specific tool is also a good investment.

5. FPGAs and ASICs are two different worlds. What applies to one not
  necessarily applies to the other. Synthesizing to LUTs and to GATEs
  isn't the same. Don't forget Synopsys is an ASIC company.
  Driving DC ins't the same as doing FPGA synthesis.

6. Significant Power consumption reduction requires other techniques
   than using case instead of if (supposing that there is any gain
   at all doing so).

7. Gate count is definitely less and less an issue, even in the
  ASIC field ! Challenges have moved, and old books don't reflect this.

My experience is : Synthesis tools are often smarter than the designer
thinks, but there are also sometimes doing some apparently "stupid"
things (at least looking like such for unexperienced designers).
Just try Q <= A + B - A - B; -- unsigned vectors.

And please do *NOT* avoid the case statement when it is appropriate !!!

Again, HDL code should be as simple, clear and expressive as possible,
easy  to understand and maintain, and not error-prone. I assign a higher
priority to these criteria in our designs.

After a good ground learning, learn by trying. This is fun anyway.
You must end up "thinking" like your synthesizer, then you'll be
real efficient.

Bert Cuzeau
   "Let's save the poor IF from damnation !" Commitee
   12, Gate(s) Lane
   Mux Island
:-)
(donations accepted, FFs* and LUTs only)
* FlipFlops, not French Francs


----------------------------
-- HOTDECOD.VHD
-- -------------------------------------
--   One-Hot Decoder
-- -------------------------------------
-- ALSE. http://www.alse-fr.com/english
-- This design must be synthesized as 3 x OR gates (4-inputs)
-- Any extra logic is unnecessary.
--

library IEEE;
   use IEEE.std_logic_1164.all;

-- -------------------------------------
     Entity HOTDECOD is
-- -------------------------------------
   port ( A : in  std_logic_vector(0 to 7);
          Q : out std_logic_vector(2 downto 0)
        );
end;

-- -------------------------------------
     Architecture RTL_case of HOTDECOD is
-- -------------------------------------
-- check how many LUTS for this one...
-- How do you code this as a generic size decoder ?
begin

process (A)
begin
   case A is
     when "00000001" => Q <= "111";
     when "00000010" => Q <= "110";
     when "00000100" => Q <= "101";
     when "00001000" => Q <= "100";
     when "00010000" => Q <= "011";
     when "00100000" => Q <= "010";
     when "01000000" => Q <= "001";
     when "10000000" => Q <= "000";
     when others =>     Q <= "---"; -- don't care
   end case;
end process;
-- Note : the "case" above is auto-full and auto-parallel in Verilog sense.
-- Quite obviously, one solution is :
--   Q2 = A0 or A1 or A2 or A3
--   Q1 = A2 or A3 or A6 or A7
--   Q0 = A1 or A3 or A5 or A7

end RTL_case;

-- -------------------------------------
     Architecture RTL_if of HOTDECOD is
-- -------------------------------------
-- and how many LUTS for this one ?
-- Isn't this description easier to rewrite under
-- the form of a (size-independant) function ?
begin

process (A)
begin
        if A(7) = '1' then Q <= "111";
     elsif A(6) = '1' then Q <= "110";
     elsif A(5) = '1' then Q <= "101";
     elsif A(4) = '1' then Q <= "100";
     elsif A(3) = '1' then Q <= "011";
     elsif A(2) = '1' then Q <= "010";
     elsif A(1) = '1' then Q <= "001";
     elsif A(0) = '1' then Q <= "000";
     else                  Q <= "---"; -- don't care
   end if;
end process;
-- do you see a "priority" in the synthesized result ???


end RTL_if;

Article: 83468
Subject: FPGA Article on Slashdot.
From: Ziggy <Ziggy@TheCentre.com>
Date: Sat, 30 Apr 2005 16:37:17 GMT
Links: << >>  << T >>  << A >>
Jusr curious if anyone ran across the recent article about a project for 
'3rd world nations' that involved a FPGA based 'thin client'.

This thing has ehternet, 2mb video ram, etc... for under 100 pounds... 
looks about the size of a VHS tape...

Not a lot of detail yet, but it sounds perfect for a lot of SoC projects...

Now the trouble would be how to get one of these beasts in single 
quantities...


http://linux.slashdot.org/article.pl?sid=05/04/29/2213203&tid=185&tid=106&tid=137

and http://www.ndiyo.org/

Article: 83469
Subject: Re: problems getting flex10k10 to work
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 30 Apr 2005 18:52:24 +0200
Links: << >>  << T >>  << A >>
LENNART KIRKEVIK wrote:

> I have a flex10k10lc84-4 and have just bulit a test circuit for it. I am 
> using the MAX+plusII software.  I made a simple AND port and compiled and 
> programmed it with a byteblaster II cable. I got no error messages, just the 
> "configuration complete". When testing, the output was low regardless of the 
> state of the inputs. The flex 10k10 seems to be dead except when programming 
> it.
> 
> Does someone have an idea ?
> 
> Lennart Kirkevik
> 
> 

Likely cause : wrong pin assignment.
Check the pin report, and verify against your schematics.
Check the equation also. So simple it shouldn't be tough.
Did you connect all Vcc and Gnd pins ?

Being able to download is a good start.
You shouldn't be far.

Bert Cuzeau


Article: 83470
Subject: Re: VGA sync signals
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Sat, 30 Apr 2005 17:17:54 GMT
Links: << >>  << T >>  << A >>
Falk,

So the Sync signals are 75 Ohm terminated as well? I thought it was just the 
RGB lines. I thought the Syncs were TTL.

Rog.

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message 
news:3dhq5tF6ttp5vU1@individual.net...
>
> "Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag
> news:M_Nce.8045$_s1.3328@newsfe6-gui.ntli.net...
>
>> 1) Simply drive the signals from the FPGA (LVTTL signal level) and not
> worry
>> about it.
>> 2) As above but put some protection diodes on the lines.
>> 3) Put series resistors in the signals (I've seen this on an old FPGA
>> board).
>
> Use series resistors of about 50 ohms. this will give you roughly 75 Ohms
> output impedance, well matched to the cable.
>
> Regards
> Falk
>
>
> 



Article: 83471
Subject: Re: Case statement illusions ?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 30 Apr 2005 10:41:10 -0700
Links: << >>  << T >>  << A >>
info_ wrote:

> They don't quite say this (or they'd lie).
> "If ... elseif" has an implied priority (first test true -> next tests
> are not taken)... but that makes no sense when you describe a truth table !
> (as in my first encoder example)

"case" and "if then else"
have no overlapping cases and therefore no priority.

"if then else elsif elsif ... "
only implies priority if cases overlap.

> I think this is the same with std_ulogic, which use was supposed
> to help detect multiple drivers situations (it did). But there
> are other ways to check this and so many other bad things are
> to be tested at synthesis that everybody has dropped now this
> unresolved type and obsolete style.

I agree that std_ulogic_vector is usually
more trouble than it's worth.
However std_ulogic has no such downside.
I use std_ulogic as my default bit type.
It port maps directly to std_logic without conversion.

    -- Mike Treseler


Article: 83472
Subject: Re: VGA sync signals
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Sat, 30 Apr 2005 17:52:22 GMT
Links: << >>  << T >>  << A >>
Falk,

Looking into this a bit more, I've found monitor input impedances in the low 
KOhms range i.e TTL type inputs.

Rog

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message 
news:3dhq5tF6ttp5vU1@individual.net...
>
> "Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag
> news:M_Nce.8045$_s1.3328@newsfe6-gui.ntli.net...
>
>> 1) Simply drive the signals from the FPGA (LVTTL signal level) and not
> worry
>> about it.
>> 2) As above but put some protection diodes on the lines.
>> 3) Put series resistors in the signals (I've seen this on an old FPGA
>> board).
>
> Use series resistors of about 50 ohms. this will give you roughly 75 Ohms
> output impedance, well matched to the cable.
>
> Regards
> Falk
>
>
> 



Article: 83473
Subject: Re: VGA sync signals
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Sat, 30 Apr 2005 21:00:29 GMT
Links: << >>  << T >>  << A >>
Roger,

Driving with 75 ohms and terminating with a relatively high impedance, for 
your case, is exactly what is needed for those LVTTL signals that need their 
signal integrity maintained. For the video and sync signals, this is 
important.

If you generate a signal with a source impedance equal to characteristic 
impedance of the associated transmission line (cable or trace), and then 
terminate the end into a high impedance, then the end will receive a full 
voltage (LVTTL level) swing -- and it will not have any signal-distorting 
reflections contained in it. This technique is called "source termination".

For this "source termination" technique, what happens is that when you drive 
a transmission line with a source of equal impedance value, the signal is 
"launched" into the transmission line at half of its source voltage (V/2). 
When the signal hits the end of the transmission line, the signal will 
double in value (in the forward direction) -- thus regenerating its original 
voltage level (V). A reflection heads back toward the source at level -V/2 
(note the minus sign). When it hits the originating end's source impedance 
the reflected wave is completely absorbed, so it doesn't reflect back to the 
destination end again.

It is possible to end terminate LVTTL, but then it must be driven into the 
transmission line at full V level. This implies that the source impedance of 
the driver be very low. In practice, this is difficult to achieve. That's 
why source termination is the most popular technique used for LVTTL (and 
like) signals that need terminating.

Bob



"Roger" <enquiries@rwconcepts.co.uk> wrote in message 
news:qBPce.8178$_s1.1100@newsfe6-gui.ntli.net...
> Falk,
>
> Looking into this a bit more, I've found monitor input impedances in the 
> low KOhms range i.e TTL type inputs.
>
> Rog
>
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message 
> news:3dhq5tF6ttp5vU1@individual.net...
>>
>> "Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag
>> news:M_Nce.8045$_s1.3328@newsfe6-gui.ntli.net...
>>
>>> 1) Simply drive the signals from the FPGA (LVTTL signal level) and not
>> worry
>>> about it.
>>> 2) As above but put some protection diodes on the lines.
>>> 3) Put series resistors in the signals (I've seen this on an old FPGA
>>> board).
>>
>> Use series resistors of about 50 ohms. this will give you roughly 75 Ohms
>> output impedance, well matched to the cable.
>>
>> Regards
>> Falk
>>
>>
>>
>
> 



Article: 83474
Subject: Re: VGA sync signals
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Apr 2005 14:01:32 -0700
Links: << >>  << T >>  << A >>
Roger, what Falk suggested is called series-termination. It matches the
drive impedance to the cable. That means the signal starts out at half
amplitude, but it doubles up when it gets reflected at the unterminated
end ( kilohm is very high impedance = unterminated.) So the receiver
sees a perfect full-amplitude signal, and all further reflections die
at the transmitter.
This is definitely the way to go.
Peter Alfke




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