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 49550

Article: 49550
Subject: MiroTech
From: "Steve Casselman" <sc@vcc.com>
Date: Thu, 14 Nov 2002 22:04:12 GMT
Links: << >>  << T >>  << A >>
Its MiroTech.. They look down for the count..

Steve


http://www.mirotech.com



Article: 49551
(removed)


Article: 49552
Subject: Re: The "Do"s and "Don't"s of Synthesizing VHDL?
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Fri, 15 Nov 2002 00:01:48 +0100
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
snip
> 
> (*) I question I've always wanted to know the answer to here. Why is it so
> common to see this sort of thing:
> 
> `ifdef VCS
> // ... some comment about avoiding a race condition ...
> #1
> `endif

some thing like this ..

http://www.deepchip.com/items/0393-04.html

-Lasse
-- 
// Lasse Langwadt Christensen
// Aalborg, Danmark

Article: 49553
Subject: Re: The "Do"s and "Don't"s of Synthesizing VHDL?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 14 Nov 2002 23:06:30 GMT
Links: << >>  << T >>  << A >>
Yikes, you guys are scaring me.  Hope these '#1' designers aren't doing safety
critical stuff.

Las--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 49554
Subject: Re: The "Do"s and "Don't"s of Synthesizing VHDL?
From: David R Brooks <daveb@iinet.net.au>
Date: Fri, 15 Nov 2002 07:24:27 +0800
Links: << >>  << T >>  << A >>
Thinking further along these lines, are there any tips for writing
*large* PLA's for FPGA's? I currently have to target 31 inputs, 260
minterms and 85 outputs to a Virtex-II. The inputs are sufficiently
scattered that it is impractical to partition it & use Block RAMs.

Currently, I use mechanically generated code thus:

LIBRARY ieee ;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
USE ieee.std_logic_unsigned.all;
USE ieee.std_logic_misc.all;

ENTITY placore IS
    PORT(
        CUR    : in  unsigned(30 downto 0);
        PLAOUT : out unsigned(84 downto 0) );
END placore ;

architecture generated of placore is

  function INSTR (                      -- Generate the AND-plane
output
    signal   ISSUED      : unsigned;    -- PLA input
    constant MASK, VALUE : unsigned)    -- Mask, & resulting value
    return boolean is
  begin
    return (ISSUED and MASK) = VALUE;
  end INSTR;

begin

mpla: process (CUR)
 variable ANS : unsigned(PLAOUT'range); -- Accumulates the OR-plane   
                                        -- result
 variable HIT : natural;                -- Count PLA "hits"

 -- Note: This code is mechanically generated from a PLA listing.
 --       Each IF block corresponds to one PLA term.

 begin  -- process mpla
   HIT := 0;
   ANS := (others => '0');

  if INSTR(CUR,"0001000000000011111111110000001",
               "0000000000000000001000000000000") then
    ANS := ANS or
"0000000010000000000000000000010000000000010000100100000000100000000000000000000111000";
    HIT := HIT + 1;
  end if;

  -- 250 more terms, similarly

  if INSTR(CUR,"0010000000000011111111111100111",
               "0010000000000001111111111000111") then
    ANS := ANS or
"0000000000000000000000000000100001000000000000100000000000000000000000000000000000000";
    HIT := HIT + 1;
  end if;

  PLAOUT <= ANS;                            -- Export the OR-plane
                                            -- result

  assert (HIT = 1) or (now < 5 ns);         -- Sanity check 
                                            -- (ignored by synthesis)
  end process mpla;

end generated;

This works (but is very slow to synthesise) with around 50 minterms,
however the full design causes XST to run out of memory. Database
Answer #15336 mentions this memory problem, but doesn't offer a
solution.
I can work around, by partitioning the PLA into 5 sections, and then
OR-ing their outputs, but it's pretty unwieldy. Is there a better way?

phil_j_connor@hotmail.com (Phil Connor) wrote:

:"Justin A. Kolodziej" <jkolodzi@students.uiuc.edu> wrote in message news:<Pine.GSO.4.31.0211111730001.3254-100000@ux13.cso.uiuc.edu>...
:> Does anyone have a pointer to a canonical list of things to do and avoid
:> doing when you want to write VHDL that has a good chance of actually
:> synthesizing correctly in Leonardo?
:> 
:> I only know that what I do tends to work better than what my students do
:> (I have the unfortunate task of TAing a class in embedded systems and
:> reprogrammable logic), but I admit that I don't have such a list of rules
:> that will guarantee that VHDL works when it is synthesized, even if it
:> works in simulation.
:> 
:> Certainly someone out there must have a list... and I don't mean the
:> "Synthesizable VHDL" subset, because even if the synthesis tools gives no
:> warnings or anything, things can break horribly when additional processes
:> are added, it seems.
:
:Hi Justin,
:
:Isn't it just a case of the VHDL having to match the software
:interpreting it, that is the synthesis tool.
:
:Packages like FPGA Express have a large manual telling you how to
:write VHDL that will be correctly synthesised. A wise person would
:follow these templates religiously.
:
:However easy to remember rules of thumb are more interesting and
:memorable.
:
:Good question!
:
:Regards
:
:Phil


Article: 49555
Subject: Re: The "Do"s and "Don't"s of Synthesizing VHDL?
From: "Clyde R. Shappee" <clydes@world.std.com>
Date: Thu, 14 Nov 2002 20:40:28 -0500
Links: << >>  << T >>  << A >>
Ick!

Maybe an alias will help to define and assign the bit fields?

Just a thought.

CRS

David R Brooks wrote:

> Thinking further along these lines, are there any tips for writing
> *large* PLA's for FPGA's? I currently have to target 31 inputs, 260
> minterms and 85 outputs to a Virtex-II. The inputs are sufficiently
> scattered that it is impractical to partition it & use Block RAMs.
>
> Currently, I use mechanically generated code thus:
>
> LIBRARY ieee ;
> USE ieee.std_logic_1164.all;
> USE ieee.std_logic_arith.all;
> USE ieee.std_logic_unsigned.all;
> USE ieee.std_logic_misc.all;
>
> ENTITY placore IS
>     PORT(
>         CUR    : in  unsigned(30 downto 0);
>         PLAOUT : out unsigned(84 downto 0) );
> END placore ;
>
> architecture generated of placore is
>
>   function INSTR (                      -- Generate the AND-plane
> output
>     signal   ISSUED      : unsigned;    -- PLA input
>     constant MASK, VALUE : unsigned)    -- Mask, & resulting value
>     return boolean is
>   begin
>     return (ISSUED and MASK) = VALUE;
>   end INSTR;
>
> begin
>
> mpla: process (CUR)
>  variable ANS : unsigned(PLAOUT'range); -- Accumulates the OR-plane
>                                         -- result
>  variable HIT : natural;                -- Count PLA "hits"
>
>  -- Note: This code is mechanically generated from a PLA listing.
>  --       Each IF block corresponds to one PLA term.
>
>  begin  -- process mpla
>    HIT := 0;
>    ANS := (others => '0');
>
>   if INSTR(CUR,"0001000000000011111111110000001",
>                "0000000000000000001000000000000") then
>     ANS := ANS or
> "0000000010000000000000000000010000000000010000100100000000100000000000000000000111000";
>     HIT := HIT + 1;
>   end if;
>
>   -- 250 more terms, similarly
>
>   if INSTR(CUR,"0010000000000011111111111100111",
>                "0010000000000001111111111000111") then
>     ANS := ANS or
> "0000000000000000000000000000100001000000000000100000000000000000000000000000000000000";
>     HIT := HIT + 1;
>   end if;
>
>   PLAOUT <= ANS;                            -- Export the OR-plane
>                                             -- result
>
>   assert (HIT = 1) or (now < 5 ns);         -- Sanity check
>                                             -- (ignored by synthesis)
>   end process mpla;
>
> end generated;
>
> This works (but is very slow to synthesise) with around 50 minterms,
> however the full design causes XST to run out of memory. Database
> Answer #15336 mentions this memory problem, but doesn't offer a
> solution.
> I can work around, by partitioning the PLA into 5 sections, and then
> OR-ing their outputs, but it's pretty unwieldy. Is there a better way?
>
> phil_j_connor@hotmail.com (Phil Connor) wrote:
>
> :"Justin A. Kolodziej" <jkolodzi@students.uiuc.edu> wrote in message news:<Pine.GSO.4.31.0211111730001.3254-100000@ux13.cso.uiuc.edu>...
> :> Does anyone have a pointer to a canonical list of things to do and avoid
> :> doing when you want to write VHDL that has a good chance of actually
> :> synthesizing correctly in Leonardo?
> :>
> :> I only know that what I do tends to work better than what my students do
> :> (I have the unfortunate task of TAing a class in embedded systems and
> :> reprogrammable logic), but I admit that I don't have such a list of rules
> :> that will guarantee that VHDL works when it is synthesized, even if it
> :> works in simulation.
> :>
> :> Certainly someone out there must have a list... and I don't mean the
> :> "Synthesizable VHDL" subset, because even if the synthesis tools gives no
> :> warnings or anything, things can break horribly when additional processes
> :> are added, it seems.
> :
> :Hi Justin,
> :
> :Isn't it just a case of the VHDL having to match the software
> :interpreting it, that is the synthesis tool.
> :
> :Packages like FPGA Express have a large manual telling you how to
> :write VHDL that will be correctly synthesised. A wise person would
> :follow these templates religiously.
> :
> :However easy to remember rules of thumb are more interesting and
> :memorable.
> :
> :Good question!
> :
> :Regards
> :
> :Phil


Article: 49556
Subject: Re: LU-decomposition
From: "Stan" <vze3qgji@verizon.net>
Date: Fri, 15 Nov 2002 05:07:23 GMT
Links: << >>  << T >>  << A >>

"fireball" <sensen@swirvemail.com> wrote in message
news:ee7a3b8.22@WebX.sUN8CHnE...
> first of all, thanks everyone for your valuable insights.
>
> equation: AX=B
> A 3x3
> X 3x1
> B 3x1
>
> Maybe i was wrong in implementing LU decomposition. So i try to write it
down in the normal way of solving the matrix inverse by first calculating
the cofactors of each, taking the adjoin matrix and divide by the
determinant. Finally, i multiply it with the B on the RHS.
>
> i dont' have experience in writing HDL so i started with verilog. But i
have problems with the dividing part, any suggestions? it say error:Xst:870
Can not use the DIV
>
> Anyone done this before? or anyone know any useful website which has a
collection of verilog examples be it matrix, arithmetic?

Synopsys will not create a divider for you, you'll have to design it
yourself.  If you do not need a lot of precision, I once did division by
inversion and multiplication, and did inversion with a table lookup.  I
created the table by writing a C program to create the verilog, then
synthesized it as gates.   My table inverted a 9-bit mantissa and produced a
9-bit quotient for use as a multiplier.  The propagation delay was about 6
or 7 gates, I think, and the total gate count was something like 1000 gates.

If you're using an FPGA with on-chip memory, you might do the inversion with
a RAM.  In the Virtex 2 family, you can have a 10-bit mantissa using a RAm
in 1Kx18 mode, and only read 10 of the data bits.

Another trick that might work for you is to use logs.  You can use a table
to convert, do muls and divs by addition and subtraction, then use a table
to convert back.

-Stan




Article: 49557
Subject: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Nov 2002 03:23:10 -0500
Links: << >>  << T >>  << A >>
It has been awhile since I have looked at any of the numbers for FPGA FF
metastability.  Can anyone point me to data on the XC2S family, Spartan
II?  I believe this can be boiled down to a simple graph for a given
clock rate product (or input change rate and FF clock rate) and a graph
of the particular FFs in question.  I know there is also an equation,
but a graph is so simple to use and can help to explain it to others.  

Is there any difference in coefficients between the internal CLB FFs,
the shift register FFs, the IOB FFs and any others that I may have
missed?  Have all of these been characterized for metastability?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 49558
Subject: Re: configuration with Altera EPC16?
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Fri, 15 Nov 2002 09:54:18 +0100
Links: << >>  << T >>  << A >>
Besides the obvious like power/ground have you checked whether the PGM[2..0]
inputs select the page that you programmed your data into? Which page are
you using? Which mode are you using to configure your 4 EP20K400 devices?
1-bit passive serial and all data in a chain, 4-bit passive serial loading
your devices in parallel or passive parallel synchronous/asynchronous?

When you convert your .sof file into an .pof file for the EPC16 there are
several options like clock source (internal/external) which in your case
probably should be set to internal. Do you use external pull-ups on nCS and
OE or are the internal pull-ups enabled?
Do you have external pull-ups on the JTAG chain?

Wolfgang
http://www.elca.de

"Charles Braquet" <charles.braquet@mppmu.mpg.de> schrieb im Newsbeitrag
news:ar09ag$103a$1@gwdu67.gwdg.de...
> Hello,
> I have an EPC16 which have to configure 4 FPGA EP20K400. I load my
> design in the APC16 using QuartusII through the JTAG interface. I also
> verify it, using an other programmer. The signals nInitConf/nConf and
> nOE/Status go high but the DClk is not toggling. This state should
> occured when the EPC16 doesn't contain design which is in contradiction
> which what the programmer tell me.
> Why the DClk doesn't run? Could you help me to configure my FPFA through
> my EPC16?
> Thanks a lot,
>



Article: 49559
Subject: Asynchronous FIFOs using Handel-C?
From: nonuschk@gmx.net (=?ISO-8859-1?Q?Bernhard_M=E4der?=)
Date: 15 Nov 2002 01:38:58 -0800
Links: << >>  << T >>  << A >>
Hi

I have to implement fast, asynchronous FIFOs using Celoxica. The
targeted speed of the FIFOs is 75 and 120 MHz with a width of 16 bits.
I'm using a Virtex-II FPGA. As part of an evaluation process, my
superior wants it to be done in "pure" Handel-C i.e. no additional
VHDL. I wonder whether that's really possible; due to the fully
synchronous and clocked nature of Handel-C, I guess not. I don't see
the way to properly generate the asynchronous FULL and EMPTY signals
and pass them between the two clock domains (signals and registers
can't be shared).

Is there any resource on the web or can anyone point me to the right
solution?

thanks for any hint
Bernhard Mäder

Article: 49560
Subject: Re: why systemc?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 15 Nov 2002 09:47:40 +0000
Links: << >>  << T >>  << A >>


Jerry wrote:

> iluvfpgas@yahoo.ca (Alfredo) wrote in message news:<afaad421.0211131255.252e949d@posting.google.com>...

>
> > Is SystemC compatible with System Verilog, Super log, or the like?
> 2. It is not, and it is good thing.
> <swithing to sarcastic mode> System Verilog and Superlog are miserable
> attempts to convert Verilog into something resembling normal programming
> or hardware description language. Since Verilog camp zealots are totally
> impervious to discussion based on issues, going any further here is pointless.
> <back to regular mode>
>

Interesting how its SystemC and not SystemAda ...



Article: 49561
Subject: Re: configuration with Altera EPC16?
From: fredrik_he_lang@hotmail.com (Fredrik)
Date: 15 Nov 2002 02:47:23 -0800
Links: << >>  << T >>  << A >>
Hi Charles,
There has been a know issue in Quartus2.0 with the EPC4 that sounds
similar to your problem. Please try the following The solution then
was to convert the .sof file into a new .pof file using the compressed
mode. (Tools -> Convert Programming files) If the bitstream is not
compressed, DCLK never starts, while if it is, evrerything works fine.
Hope this helpes.
Fredrik
Charles Braquet <charles.braquet@mppmu.mpg.de> wrote in message news:<ar09ag$103a$1@gwdu67.gwdg.de>...
> Hello,
> I have an EPC16 which have to configure 4 FPGA EP20K400. I load my 
> design in the APC16 using QuartusII through the JTAG interface. I also 
> verify it, using an other programmer. The signals nInitConf/nConf and 
> nOE/Status go high but the DClk is not toggling. This state should 
> occured when the EPC16 doesn't contain design which is in contradiction 
> which what the programmer tell me.
> Why the DClk doesn't run? Could you help me to configure my FPFA through 
> my EPC16?
> Thanks a lot,

Article: 49562
Subject: Re: Has anyone tried Lattice's chips?
From: symon_brewer@hotmail.com (Symon)
Date: 15 Nov 2002 03:08:16 -0800
Links: << >>  << T >>  << A >>
Hey Mark,
        No worries! As a non-bitter ex-colleague of yours, I'm
interested in who the mysterious Mr. Andrews could be. I hereby give
you permission ;-) to email me on this one occasion! (Joke free mind
you! My company email still works for now!)
        We had the Lattice reps in the other day, (thanks mate!) and
my impression of the software and thoughts on the parts matched that
of Marc, the other poster in this thread. I've no experience of the
support, so can't comment.
        The hard SONET/SDH bit is neat, but if you've got the HDL IP
for that, it's is easy to reuse in whichever X or A part you want, and
the FPGA resource can be reused for other stuff if you have operating
modes that don't need SONET.
        Also, Is it true that the SER bit of the SERDES doesn't meet
the Tx SONET jitter specs? If so, SONET apps would need an external
de-jitter device anyway, so why not use Virtex II pro / Stratix SERDES
features and have higher gate count capability?
              later mate, Symsx.

"Mark Smith" <mark.smith@latticesemi.com> wrote in message news:<BqEA9.4299$R5.2396272@nnrp1.ptd.net>...
> Hmmm...Interesting...
> 
> It would seem that Mr. Andrews (That's not his name if he's who I think he
> is) is trying to get me in trouble.
> 
> juglugs@hotmail.com DOES work for Lattice - It's me...
> Also, Mr. Andrews uses one of my favorite tag lines, (and, apparently the
> same ISP) which gives me some idea as to his identity...
> 
> I believe he's a bitter ex-colleague of mine from a previous company.
> 
> I mean, honestly, does anyone who actually knows me REALLY think I'd be in
> front of a PC at 9:43 on a Friday evening??? :-)
> 
> Symx - Didn't understand your email to begin with - thought you were talking
> about my reply to your Google thing, with which I'd identified myself to
> you.....and no jokes, promise...
> 
> Best regards
> 
> Mark
>

Article: 49563
Subject: Re: Registering inputs or outputs of modules
From: mschreiber75@yahoo.com (M Schreiber)
Date: 15 Nov 2002 05:32:22 -0800
Links: << >>  << T >>  << A >>
> Putting registers on the I/O of the design alleviates the need for the
> synthesis tools to try to optimize across module boundaries.  As we move into
> larger devices and get into more of a modular designflow, you'll generally 
> want to at least register the module outputs, just to maintain consistency 
> intiming.  When you don't have registers, it can be ugly trying to trace a
> delay path, and the synthesistools will not be able to optimize through a 
> module boundary unless both the module and the next levelup are visible at
> the time of the compilation.


These module boundaries that you are talking about..are you referring
to vhdl or verilog modules within the design.  If so are you really
registering all of your outputs?  In a few recent designs I have
created a bunch of Bus mux's that let a variety of modules "talk" on
one single data bus.  Typically on these blocks I neither registered
the input or the output of theses signals.  I didn't want to incur any
latency.  I have not run into any timing problems yet, but should I be
registering these types of signals?

Article: 49564
Subject: cpld pin configuration is wrongly assigned
From: ssbhide@rediffmail.com (suchitra)
Date: 15 Nov 2002 05:43:37 -0800
Links: << >>  << T >>  << A >>
hello all
I am programming XC9536 xl cpld using webpack's impact for the first time.
When i programme the cpld it doesnot give any error or warning.
But actually i am not achieving the functionality.
May be because of wrong pin assignment or some other problem.
Can any one of u guide me.

Article: 49565
Subject: Re: cpld pin configuration is wrongly assigned
From: nospam <nospam@please.com>
Date: Fri, 15 Nov 2002 14:32:45 +0000
Links: << >>  << T >>  << A >>
ssbhide@rediffmail.com (suchitra) wrote:

>I am programming XC9536 xl cpld using webpack's impact for the first time.
>When i programme the cpld it doesnot give any error or warning.
>But actually i am not achieving the functionality.
>May be because of wrong pin assignment or some other problem.
>Can any one of u guide me.

Why do you need guiding? Your analysis of the problem is excellent. It most
certainly is "because of wrong pin assignment or some other problem".



Article: 49566
Subject: Re: C\C++ to VHDL Converter
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Fri, 15 Nov 2002 09:42:40 -0500
Links: << >>  << T >>  << A >>
Ray,

It appears you are using your HDL for, more or less, a netlister.  I have no
problem with parameterized modules, that's the way this stuff SHOULD be
done, whether HDL or schematic.  It's above that level that I really care
about...and personally, I believe schematics (or some graphical interface)
is far more functional for most humans to understand/work with.

If the HDL synthesizers weren't 10-30 times the cost of the schematic
programs, I'd buy part of the argument about tools...and with every new
synthesizer, you have to spend time learning it...though the HDL may be
portable, the tool operation (and results) isn't.

One of the main reasons customers have been asking for HDL designs is
because that's what they are being told to do...by who else, the tool and
FPGA vendors.  It's supposed a selling point, though, only until recently,
it really didn't work well at all.  For about 5 years I was getting a call
per week about how a client was told by "someone" (tool vendor or FPGA
vendor) how they had to use synthesis, it would solve all their
problems...and so they did...and their design wouldn't get above 10MHz, and
wouldn't fit in the part...and I was asked to fix the problem.  As you and I
have pointed out many times, a tool is only as good as the person using it
can make it, and the point is, though you can do netlist design in HDL, the
typical user of HDL will not be doing so, and as such, is relying on tool
"efficiency" for logic density and speed.  Fortunately for the "mainstream"
HDL user, the FPGAs are a lot faster and denser, so it hides the foibles of
HDL, and the tools have gotten a LOT better in the past three years.

To be able to match schematics ability to do critical logic mapping and
placement is relatively new to HDL, and yes, that does make it able to match
schematics in performance and density ability (for the netlisted logic that
is), as you really are not using the synthesizer to do any synthesizing...I
guess that's a good thing.

I also believe this ability is somewhat tool specific?  Are the mapping and
placement abilities of HDLs cross tool abilities?  Will the highly mapped
and placed HDL code used for Synplify work with FPGA Express?  That, of
course, is a major issue in touting portability if it is not, as you ARE
relying on a single vendor for the tool, just like you are with schematic,
though not as entirely...as the code can be massaged to "work", but not
necessarily as well as it would with the tool it was intended for.

Regards,

Austin


"Ray Andraka" <ray@andraka.com> wrote in message
news:3DD2F558.13CA7450@andraka.com...
>
>
>
> Austin Franklin wrote:
>
> > I don't understand.  What tools are you talking about?  I simply run my
> > testbench, written in HDL, same as I would for any design even if the
design
> > is in HDL, and get the same output waveforms...or better yet, it
displays
> > the actual signals on the schematics.
>
> My viewlogic license is only enabled for viewsim and viewdraw.  It doesn't
> support the viewlogic VHDL, that was extra. Frankly, the Viewlogic VHDL is
quite
> poor compared to Modelsim or Aldec.
>
> > What about placement?  Problems I've had were the tools didn't allow the
use
> > of consistent names, either when a change was made with to either the
> > design, or the toolset.
>
> I haven't had much problems with placement, at least not with stuff
instantiated
> in the code (that is one of the major reasons I do as much structural
> instantiation as I do).  Only inferred logic changes its names,
instantiated
> logic generally does not.  Inferred flip-flops generally take on the name
of the
> output net, so there is no problem floorplanning using inferred
flip-flops.  The
> LUTs do tend to get random names, so they are not as easy to deal with in
> floorplanning, but then if you do your design with one level of logic, the
> mapper packs them with the flip-flops anyway.
>
> > And what preculdes you from doing that with schematics?  Did you ever
see
> > Philip's tool for generating schematic elements?
>
> Yes, I did, and it is a very nice tool too.  I never did get my own copy
because
> just as he came out with it I was in the middle of a transition to HDLs.
HDLs
> give you that capability without having to obtain an add on tool.
>
> >
> >
> > >  The advantage is if I make a change to the macro, it only gets
changed
> > > in one place, which is not necessarily true with schematics (using 2
bit
> > slices
> > > for arithmetic, it is almost true, but you still have the special
cases at
> > the
> > > start and end of a carry chain).  The parameterization includes
options
> > for
> > > layout, assignment to different device families (RLOC format for
example),
> > > automatic signed/unsigned extension, automatic selection of reset
vector
> > values
> > > with the proper FDRE/FDSE etc.  These are things that were a little
> > awkward with
> > > schematics, and are very easy to do with the HDL generates.
> >
> > Hum, I don't find them awkward at all with schematics, but do with
HDLs...
>
> For example, say you have (this is from a design that I did with
schematics) a
> bank of 128 129 bit LFSRs.  Each is identical except it has a different
reset
> value.  With an HDL, you can construct one parameterized module that
generates
> the proper combination of sets and resets without ever having to look
inside the
> module, then you can instantiate those 128 modules in a generate statement
that
> indexes a constant array (probably in a package in another file so that
you
> never have to modify the source even if you change the constants) to
> parameterize the initial values of each module.  If I want to change the
intial
> values, I just edit the list of initial values, which by the way can be
> expressed as binary, decimal, hex, octal or any mix of that you like.
With
> schematics, you need to generate each module using FDREs and FDSEs.  As I
> recall, Philips tool didn't do this readily, and it certainly didn't read
the
> init values out of a common file.  Similarly, I can set up filter
coefficients
> for distributed arithmetic filters as a naturally ordered list of
coefficients
> in a separate package.  My VHDL filter is parameterized to read the
coefficients
> from a file, process them (with a procedure) to create the init values for
the
> DA LUTs, and then build the filter including placement.  The code is
> parameterized for the coefficient width, filter add tree width, bits per
clock,
> length of the filter etc, and I never have to go inside that module to
modify
> anything.   It took a while to build the library to where I was as
productive
> with VHDL as I was with schematics, but I am now well past there.
>
> > Mainstream?  Not really.  Synplify may be the "tool de Jour", but I
don't
> > see that as being any better than schematics, though you are locked to a
> > single vendor with schematics, no doubt.  Also, as you know, every damn
> > revision of these HDL compilers generates different code...which reeks
havoc
> > on some designs.
>
> Depends on the definition of mainstream, I suppose.   Where I come from,
> mainstream means that which most people are doing, not what which is
'best'.
> When all of my customers are asking for an HDL design flow, I think that
can be
> described as the mainstream.  Schematic entry for FPGA design, like it or
not,
> can't really be considered mainstream anymore, at least by the definition
of
> mainstream I am familiar with.  You can get around the variations between
> compilers by using structural generation for the critical parts of your
design.
> We do it in a large percentage of each of our designs.  As an indicator, I
spend
> far more time tweaking things for PAR than I do for getting the synthesis
to
> turn out what I want.
>
> >
> > I agree.  Designs I do for my own projects, I do in schematics...simply
> > because it keeps the parts cost down, ups the speed significantly...and
I
> > don't have to wrestle with the tools.  I do mostly HDL work for clients
now,
> > as for misbegotten reasons, they believe it saves them time and
money...when
> > in every instance, it absolutely, unquestionably does not.
>
> I'm not sure an HDL will save money or not.  Because my library is far
more
> parameterized than I was able to achieve with schematics, and because I
have the
> option of structural cosntruction where it matters or RTL level coding
where
> things are not as critical, my design capture is perhaps a little bit
shorter
> than it was with schematics.  I have seen tremendous gains in the
simulation
> however because the sophistication of the testbenches is much higher.
>
> >
> >
> > > So will I be seeing you in San Jose tomorrow?  If so, we can discuss
this
> > in
> > > person.
> >
> > No, sigh...I am unable to make it, but I was assured by Philip that you
> > would defend the fort better than either of us would ;-)
>
> Depends which fort.  I don't defend the schematic fort anymore.  I got out
of
> there right before it burned down around me.  As for using a mix of
schematics
> and HDLs, I find that more awkward than using either...it means
maintaining two
> libraries, proficiency on additional tools and customers griping louder
because
> of more tools needed to support a design.  You missed a good meeting, They
were
> very receptive and have been following up this week (which is something we
> didn't see before).
>
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 49567
Subject: Re: Microblaze
From: John Linn <John.Linn@xilinx.com>
Date: Fri, 15 Nov 2002 08:33:41 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7D562A6C48D4E41411046FE1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There is now a port of uCOS-II at
http://ucos-ii.com/contents/products/ucos-ii/ports-misc.html for
Microblaze.

Thanks,
John Linn

John Williams wrote:

> Hi folks,
>
> I am doing some research into the Microblaze architecture - Xilinx doco
> states that there is no operating system support - it seems they (for
> now) expect microblaze to run a monolithic application.
>
> I've looked around but not found anything substantial - does anybody
> know about any operating system ports to microblaze, either free or
> otherwise?  I found a press release from Xilinx and Wind River talking
> about vxWorks, but no further mention of it on either's website.  I'd
> love to hear about any budding linux / uClinux / other ports, or indeed
> any microblaze developers' mailing lists and resources etc.
>
> thanks,
>
> John



Article: 49568
Subject: Webpack and Virtex Pro?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 15 Nov 2002 08:17:37 -0800
Links: << >>  << T >>  << A >>
Has Xilinx said anything about future versions of WebPack being able
to support the 2VP4?  It seems a shame that it doesn't support at
least one part that actually contains a PowerPC processor.  The number
of logic cells in the 2VP4 is comparable to those in the largest
Spartan IIE part that WebPack supports, so if the criterion is still
"marketing gates", the 2VP4 ought to qualify.  Oh, wait, how many
marketing gates are in a PowerPC?  :-)


Article: 49569
Subject: Re: Microblaze
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Fri, 15 Nov 2002 16:29:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
>John Williams wrote:
>>
>> I am doing some research into the Microblaze architecture - Xilinx doco
>> states that there is no operating system support - it seems they (for
>> now) expect microblaze to run a monolithic application.
>>
>> I've looked around but not found anything substantial - does anybody
>> know about any operating system ports to microblaze, either free or
>> otherwise?

There's a middle ground between a monolithic application and
a traditional operating system.  Take a look at uCR
   http://icarus.com/ucr/uCR.html
which should run with negligible effort on any processor
targeted by gcc.

        - Larry

Article: 49570
Subject: Re: Metastability in FPGAs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 15 Nov 2002 17:52:45 +0100
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:3DD4AEEE.F91B76D3@yahoo.com...
> It has been awhile since I have looked at any of the numbers for FPGA FF
> metastability.  Can anyone point me to data on the XC2S family, Spartan
> II?  I believe this can be boiled down to a simple graph for a given
> clock rate product (or input change rate and FF clock rate) and a graph
> of the particular FFs in question.  I know there is also an equation,
> but a graph is so simple to use and can help to explain it to others.
>
> Is there any difference in coefficients between the internal CLB FFs,
> the shift register FFs, the IOB FFs and any others that I may have
> missed?  Have all of these been characterized for metastability?

Have a look at the latest techXclusive from Peter Alfke, where he provides
numbers and graphs for Virtex-IIPRO. As far as I remember there is also a
graph with the 4 k Series, so Spartan-II should be somewhere inbetween.

--
MfG
Falk





Article: 49571
Subject: Re: Registering inputs or outputs of modules
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 15 Nov 2002 09:38:27 -0800
Links: << >>  << T >>  << A >>
M Schreiber wrote:


> These module boundaries that you are talking about..are you referring
> to vhdl or verilog modules within the design.


Yes, entity/component instances in VHDL speak.

> If so are you really
> registering all of your outputs?  In a few recent designs I have
> created a bunch of Bus mux's that let a variety of modules "talk" on
> one single data bus.  Typically on these blocks I neither registered
> the input or the output of theses signals.  I didn't want to incur any
> latency.  I have not run into any timing problems yet, but should I be
> registering these types of signals?


This thread started about style guidelines for new code, 

not a critique of working code.


Lots of designers use asynchronous processes or things like muxes.
If that's how you see it, that's how you should code it.

I see muxes as part of a data path that eventually gets to
registers. I would put all registers that need the mux
into the same entity/module.

Variables are handy for doing gating on the
D side of the registers.

  -- Mike Treseler



Article: 49572
Subject: Re: EPP slave interface
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Fri, 15 Nov 2002 18:58:33 +0100
Links: << >>  << T >>  << A >>
Steve,

Sorry for that.
I will add our synchronous EPP core ( VHDL source) on our Amontec server 
this week-end.
Please visit www.amontec.com by next monday.

Regards,
Laurent Gauch

Steven Derrien wrote:
> Hi Laurent, 
> 
> Laurent Gauch wrote:
> 
>>Try Chameleon POD on www.amontec.com
>>
> 
> 
> Do you have any specific link ? I have browsed through your website
> but I could not find anything related to an EPP vhdl core.
> 
> Thank you,
> 
> Steven


Article: 49573
Subject: Re: Asynchronous FIFOs using Handel-C?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 15 Nov 2002 10:16:45 -0800
Links: << >>  << T >>  << A >>


Bernhard Mäder wrote:

> I don't see
> the way to properly generate the asynchronous FULL and EMPTY signals
> and pass them between the two clock domains (signals and registers
> can't be shared).


I agree. So try a fast synchronous FIFO.



> Is there any resource on the web or can anyone point me to the right
> solution?


I saw some app notes on celoxica.com.

If the boss wants a benchmark, do it in both Handel-C and
in an HDL.

  -- Mike Treseler


Article: 49574
Subject: Re: C\C++ to VHDL Converter
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 15 Nov 2002 10:27:30 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote:


> I also believe this ability is somewhat tool specific?  Are the mapping and
> placement abilities of HDLs cross tool abilities?  


Is there a schematic file format that crosses tool boundaries?

       -- Mike Treseler




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