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
2017JanFebMarApr2017

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 19175

Article: 19175
Subject: Re: Question to synplicity users and other not Leonardo users,
From: Jonas Thor <thor@sm.luth.se.NoSpam>
Date: Fri, 03 Dec 1999 15:32:11 +0100
Links: << >>  << T >>  << A >>
Hi,

Synplify 5.2.2.infers a LDCP with G and D connected to logic '0'.
inv(R) is connected to CLR and inv(S) is connected to PRE. 

However Synplify issues this warning:

|Latch o with both set and reset is not supported yet

But it seems to support it since the output is what you should expect

/ Jonas  
Article: 19176
Subject: Re: Problems with routing Virtex device
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Dec 1999 09:44:01 -0500
Links: << >>  << T >>  << A >>
Power and ground are routed after all the active signals since you don't have
timing constraints on power and ground.  Your chosen placement is congesting the
routes enough that there is no way to route the power or ground signal to a
particular spot in the design.  When doing the floorplanning, you need to watch
out for excessive routing congestion as well as the distances on critical
routes.  Virtex does have a large routing resource, but it is far from infinite.

You might also be forcing more ground/power pins on your CLBs if you are
specifying the primitives, so it would be worth a check.

Johan Ditmar wrote:

> Hi there,
>
> I am implementing a design on a Xilinx Virtex 1000 device and I have some
> problems with routing my design:
>
> Routing active routes does not take that long, maybe a few hours, but
> routing PWR/GND gives a lot of problems. It happens often, that PAR simply
> 'hangs' at that point, by getting into some kind of loop. I have been
> waiting many hours and it never finishes. I have to change my design then
> (by changing the placement constraints in my .ucf file) and sometimes that
> works. This is the case for both rather small and large designs.
>
> This has happened many times and the only special thing about my design is
> that I have a lot of placement constraints and carry chains. This might make
> routing difficult, but why does PAR hang on routing PWR/GND then and not
> active routes? Does someone else have this problem as well?
>
> Johan



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19177
Subject: Re: Tristate bidirectional pads with Xilinx
From: Davide Falchieri <davide.falchieri@bo.infn.it>
Date: Fri, 03 Dec 1999 16:16:39 +0100
Links: << >>  << T >>  << A >>
Hello,
  thank you very much for your help. 


Here's a piece of my VHDL code with wrong tristate bidirectional pads:

entity chip is
port(
     fiben_n:  in std_logic;
     fidir:    in std_logic;
     fbten_n : inout std_logic;
     fbctrl_n: inout std_logic;
     fbd:      inout std_logic_vector(31 downto 0);
     ...);


architecture

signal state: std_logic_vector(2 downto 0);

begin

fbd      <= fbd_int      when (fidir = '1' and fiben_n = '0') else
(others => 'Z');
fbctrl_n <= fbctrl_n_int when (fidir = '1' and fiben_n = '0') else 'Z';
fbten_n  <= fbten_n_int  when (fidir = '1' and fiben_n = '0') else 'Z';

process     -- state machine
begin  
  wait until ck'event and ck='1';
  case state is
       when "000" =>
         if(fbten_n = '0' and fbctrl_n = '0' and fiben_n = '0' and fidir
= '0') then
            if(fbd(7 downto 0) = "00110011") then
               state <= "001";
            else
               state <= "000";
            end if;
         else
            state <= "000";
         end if;
       when "001" => 
         if(fiben_n = '0' and fidir = '1') then
           fbd_int      <= internal_data;
           fbten_n_int  <= '0';
           fbctrl_n_int <= '1';
         else
           fbten_n_int  <= '1';
           fbctrl_n_int <= '1';
         end if;
         state <= "001";
   ...
   ...

When state is "000" all the bidirectional pins (fbten_n, fbctrl_n, fbd)
are driven from outside;
when state is "001" I have to drive the bidirectional pins.

After Synopsys synthesis I get the pads IOBUF_N_S on the bidirectional
nets with tristate control and all seems right. But the test of the
board fails: fbten and fbten_int are different even when they should
have the same value.
I don't really know where the problem might be.


Still thank you very much for your help.


Davide




_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
                                                      
                      Davide Falchieri                
           Physics Department, Bologna University     
        40127,Viale Berti Pichat 6/2, Bologna(ITALY)      
          TEL:+39-051-2095077, FAX:+39-051-2095297          
           URL:http://sunvlsi4.bo.infn.it/~davide     
            mailto:davide.falchieri@bo.infn.it     
                                                      
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Article: 19178
Subject: Help with ROM in Xilinx Virtex
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 3 Dec 1999 11:37:50 -0500
Links: << >>  << T >>  << A >>
Greetings;

I'm hoping this is a simple question to answer.

When I wanted to put a ROM into an XC4000, I ran Logiblox. Within that tool,
I was able to specify the data values, size, etc.. Now I want to do the same
with Virtex. However, after installing a fresh copy of M2.1i, the Logiblox
tool doesn't offer Virtex as a device family. I also tried CoreGen, but it
doesn't offer ROM's for the Virtex family (the option is greyed out). From
what I can tell, this tool will only create Block RAM components for Virtex.
The ROM I need is relatively small, so I prefer not to use the larger Block
RAM elements.

Anyhow, I would really appreciate it if someone could tell me how to
generate ROM for Virtex. I haven't ruled out the possibility that I
installed M2.1i improperly. However, I did select the data files for the
Virtex devices I'd be using, and I'm able to do complete Virtex designs.

Thanks in advance,
Jamie Sanderson


Article: 19179
Subject: Re: Tristate bidirectional pads with Xilinx
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 3 Dec 1999 10:00:50 -0700
Links: << >>  << T >>  << A >>
Davide Falchieri wrote in message <3847DED7.446B9B3D@bo.infn.it>...
>Hello,
>  thank you very much for your help.
>
>
>Here's a piece of my VHDL code with wrong tristate bidirectional pads:
>
>entity chip is
>port(
>     fiben_n:  in std_logic;
>     fidir:    in std_logic;
>     fbten_n : inout std_logic;
>     fbctrl_n: inout std_logic;
>     fbd:      inout std_logic_vector(31 downto 0);
>     ...);
>
>
>architecture
>
>signal state: std_logic_vector(2 downto 0);
>
>begin
>
>fbd      <= fbd_int      when (fidir = '1' and fiben_n = '0') else
>(others => 'Z');
>fbctrl_n <= fbctrl_n_int when (fidir = '1' and fiben_n = '0') else 'Z';
>fbten_n  <= fbten_n_int  when (fidir = '1' and fiben_n = '0') else 'Z';
>
>process     -- state machine
>begin
>  wait until ck'event and ck='1';
>  case state is
>       when "000" =>
>         if(fbten_n = '0' and fbctrl_n = '0' and fiben_n = '0' and fidir
>= '0') then
>            if(fbd(7 downto 0) = "00110011") then
>               state <= "001";
>            else
>               state <= "000";
>            end if;
>         else
>            state <= "000";
>         end if;
>       when "001" =>
>         if(fiben_n = '0' and fidir = '1') then
>           fbd_int      <= internal_data;
>           fbten_n_int  <= '0';
>           fbctrl_n_int <= '1';
>         else
>           fbten_n_int  <= '1';
>           fbctrl_n_int <= '1';
>         end if;
>         state <= "001";
>   ...
>   ...
>
>When state is "000" all the bidirectional pins (fbten_n, fbctrl_n, fbd)
>are driven from outside;
>when state is "001" I have to drive the bidirectional pins.
>
>After Synopsys synthesis I get the pads IOBUF_N_S on the bidirectional
>nets with tristate control and all seems right. But the test of the
>board fails: fbten and fbten_int are different even when they should
>have the same value.
>I don't really know where the problem might be.

It looks like you never get out of state "001" - perhaps the synthesis tool
is being clever and optimizing away the rest of your state machine?


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

The secret of Slurm is on a need-to-know basis.



Article: 19180
Subject: Re: Help with ROM in Xilinx Virtex
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Dec 1999 13:02:45 -0500
Links: << >>  << T >>  << A >>
No, you installed them fine.  This is yet another example of my assertion that
the virtex tools are not yet ready for prime time.  Nice silicon, but the tools
are still quite buggy, the libraries are incomplete, and support for anything
other than the push the big green button synthesized designs is negligable at
best (just try simulating a schematic, or see what happens when you try to hand
pack a CLB with RLOCs).

You'll have to build your own macro to do the ROM in CLBs.  If speed isn't
critical, then you might get away without doing the placement too.  Use the LUT
primitives and put the right inits on them.  You can write a piece of VHDL code
to take your data and generate LUTs out of it.  If you need to, you can also put
RLOCs on the LUTs.

Jamie Sanderson wrote:

> Greetings;
>
> I'm hoping this is a simple question to answer.
>
> When I wanted to put a ROM into an XC4000, I ran Logiblox. Within that tool,
> I was able to specify the data values, size, etc.. Now I want to do the same
> with Virtex. However, after installing a fresh copy of M2.1i, the Logiblox
> tool doesn't offer Virtex as a device family. I also tried CoreGen, but it
> doesn't offer ROM's for the Virtex family (the option is greyed out). From
> what I can tell, this tool will only create Block RAM components for Virtex.
> The ROM I need is relatively small, so I prefer not to use the larger Block
> RAM elements.
>
> Anyhow, I would really appreciate it if someone could tell me how to
> generate ROM for Virtex. I haven't ruled out the possibility that I
> installed M2.1i improperly. However, I did select the data files for the
> Virtex devices I'd be using, and I'm able to do complete Virtex designs.
>
> Thanks in advance,
> Jamie Sanderson



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19181
Subject: Re: Help with ROM in Xilinx Virtex
From: "Ernesto Guevara" <ernesto@ANTISPAMrdx.com>
Date: Fri, 03 Dec 1999 18:20:34 GMT
Links: << >>  << T >>  << A >>
Hello,
I'm not trying to be facetious, but this is a
question for Xilinx tech support.
What do they say?

Jamie Sanderson <jamie@nortelnetworks.com> wrote in message
news:828rku$c6k$1@bcrkh13.ca.nortel.com...
> Greetings;
>
> I'm hoping this is a simple question to answer.
>
> When I wanted to put a ROM into an XC4000, I ran Logiblox. Within that
tool,
> I was able to specify the data values, size, etc.. Now I want to do the
same
> with Virtex. However, after installing a fresh copy of M2.1i, the Logiblox
> tool doesn't offer Virtex as a device family. I also tried CoreGen, but it
> doesn't offer ROM's for the Virtex family (the option is greyed out). From
> what I can tell, this tool will only create Block RAM components for
Virtex.
> The ROM I need is relatively small, so I prefer not to use the larger
Block
> RAM elements.
>
> Anyhow, I would really appreciate it if someone could tell me how to
> generate ROM for Virtex. I haven't ruled out the possibility that I
> installed M2.1i improperly. However, I did select the data files for the
> Virtex devices I'd be using, and I'm able to do complete Virtex designs.
>
> Thanks in advance,
> Jamie Sanderson
>
>


Article: 19182
Subject: Solution: ROM in Xilinx Virtex
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 3 Dec 1999 14:25:36 -0500
Links: << >>  << T >>  << A >>
You make a good point. On the other hand, that could be said about many
things posted here. My experience is that not only do I often get an answer
very quickly here, but I also get the chance to commiserate...

I'm using Synplify, which I already knew could automatically infer RAM
elements. I imitated their example for RAM, and included constant
assignments to each element of the array. After synthesis, there is a block
called ROM in the RTL view. It seems to work in post-PAR simulation too. I
guess this is a case of the documentation lagging behind the functionality.

Cheers,
Jamie

Ernesto Guevara <ernesto@ANTISPAMrdx.com> wrote in message
news:SRT14.9832$7K5.249208@cmnws01.we.mediaone.net...
> Hello,
> I'm not trying to be facetious, but this is a
> question for Xilinx tech support.
> What do they say?



Article: 19183
Subject: Re: Solution: ROM in Xilinx Virtex
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Dec 1999 16:44:13 -0500
Links: << >>  << T >>  << A >>
Yes, synplicity does ROM too.  It's the same as RAM except the write input is
tied off inactive.  It won't be placed in any kind of order, and in older
versions of synplicity it sometimes optimized the ROM into gates.

Jamie Sanderson wrote:

> You make a good point. On the other hand, that could be said about many
> things posted here. My experience is that not only do I often get an answer
> very quickly here, but I also get the chance to commiserate...
>
> I'm using Synplify, which I already knew could automatically infer RAM
> elements. I imitated their example for RAM, and included constant
> assignments to each element of the array. After synthesis, there is a block
> called ROM in the RTL view. It seems to work in post-PAR simulation too. I
> guess this is a case of the documentation lagging behind the functionality.
>
> Cheers,
> Jamie
>
> Ernesto Guevara <ernesto@ANTISPAMrdx.com> wrote in message
> news:SRT14.9832$7K5.249208@cmnws01.we.mediaone.net...
> > Hello,
> > I'm not trying to be facetious, but this is a
> > question for Xilinx tech support.
> > What do they say?



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19184
Subject: Re: Tristate bidirectional pads with Xilinx
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 03 Dec 1999 19:27:13 -0500
Links: << >>  << T >>  << A >>
Davide Falchieri wrote:
> 
> Hello,
>   thank you very much for your help.
> 
> Here's a piece of my VHDL code with wrong tristate bidirectional pads:
> 
> entity chip is
> port(
>      fiben_n:  in std_logic;
>      fidir:    in std_logic;
>      fbten_n : inout std_logic;
>      fbctrl_n: inout std_logic;
>      fbd:      inout std_logic_vector(31 downto 0);
>      ...);
> 
> architecture
> 
> signal state: std_logic_vector(2 downto 0);
> 
> begin
> 
> fbd      <= fbd_int      when (fidir = '1' and fiben_n = '0') else
> (others => 'Z');
> fbctrl_n <= fbctrl_n_int when (fidir = '1' and fiben_n = '0') else 'Z';
> fbten_n  <= fbten_n_int  when (fidir = '1' and fiben_n = '0') else 'Z';
> 
> process     -- state machine
> begin
>   wait until ck'event and ck='1';
>   case state is
>        when "000" =>
>          if(fbten_n = '0' and fbctrl_n = '0' and fiben_n = '0' and fidir
> = '0') then
>             if(fbd(7 downto 0) = "00110011") then
>                state <= "001";
>             else
>                state <= "000";
>             end if;
>          else
>             state <= "000";
>          end if;
>        when "001" =>
>          if(fiben_n = '0' and fidir = '1') then
>            fbd_int      <= internal_data;
>            fbten_n_int  <= '0';
>            fbctrl_n_int <= '1';
>          else
>            fbten_n_int  <= '1';
>            fbctrl_n_int <= '1';
>          end if;
>          state <= "001";
>    ...
>    ...
> 
> When state is "000" all the bidirectional pins (fbten_n, fbctrl_n, fbd)
> are driven from outside;
> when state is "001" I have to drive the bidirectional pins.
> 
> After Synopsys synthesis I get the pads IOBUF_N_S on the bidirectional
> nets with tristate control and all seems right. But the test of the
> board fails: fbten and fbten_int are different even when they should
> have the same value.
> I don't really know where the problem might be.

I am not sure if I understand the problem. The tristate and bus pins are
controlled by the combination of fidir and fiben_n. These sound like
direction (read = high) and enable (low true) signals. When being read,
the internal data (*_int) is output onto the bus and two "extra" control
signals. The state machine is further controlled by the bus control pins
as well as the "extra" control signals. The machine in turn controls the
two internal versions of the two "extra" control signals. 

Your statement about the signals being driven from the outside in state
"000" is not exactly correct. Your design will drive the bidir pins
anytime the two bus control signals are in the "read" state. This can
happen when your machine is in state "000". In fact it is expected to
happen according to the state machine code. This is what triggers a
transistion to state "001". Likewise, unless your external logic selects
the read mode, your design will not drive the tristate signals in the
"001" state. 

This is a rather complex design since the two "extra" control signals
constitute feedback for the state machine and may well be complicating
the state table beyond what you had planned. On top of that, your state
machine (or what you have shown here) has a stuck state of "001". Once
entered, there is no exit. Finally, you don't specify the state of the
two internal "extra" control signals in the "000" state, so they will
retain the last value assigned in a previous state. 

So it is very difficult to help you debug this design. The operation of
the design is not clear from your code fragment and the operation may
well be more complex than you had intended. My guess is that you have
some problems in your state machine, but without the full state
machine/design description and code, it is not possible to tell. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 19185
Subject: Re: backup fifo's
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 03 Dec 1999 19:32:19 -0500
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> 
> Hi Bruce,
> 
> No, this problem still exists.  If you are bus mastering a write,
> there are several ways the transaction can end.  One of these
> is disconnect without data by the target.  In such a case, you
> (the bus master) will have popped data out of the FIFO, and
> it will be sitting in the I/O output flip flops.  At this point, if the
> target disconnects without taking it, your FIFO is out of
> sync.
> 
> This behavior is described in section 3.3.3.2.1 "Target
> Termination Signaling Rules" of the PCI 2.2 specification.
> 
> Also keep in mind that this is only an issue if your data source
> is not prefetchable.  If the data source is prefetchable and you
> are using the FIFO as a rate matching buffer, you can simply
> flush the buffer when you are done.
> 
> Incidentally, backing up a FIFO built from RAM and address
> pointers (counters) is very easy; you just have to use an up/down
> counter for the read address pointer.
> 
> Thanks,
> Eric Crabill

I am not throughly familiar with the PCI bus spec, so I don't completely
understand the timing issues here. But couldn't you solve this problem
by just not popping the data off of the FIFO until you are sure the the
transaction is complete? I don't know how your fifo is constructed, but
all of the ones I have seen allow you to read the data without removing
the data from the fifo. 

Or is this not possible because of timing when in a streaming
stituation? 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 19186
Subject: Re: Command line for FPGA Express
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 03 Dec 1999 23:09:21 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------9C2F1FECA18BEBBABEB6079B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I created some makefiles in Win95 that run fe_shell and the Xilinx implementation tools so I could do batch file compilations of VHDL into .BIT and .SVF files.  I could write a small explanation and present them if anyone is interested.  But I think there is a tool called xflow in M2.1 that gives you command-line control of the tools now.



Mark van de Belt wrote:

> Hello,
>
> I looked into this fe shell, and it is possible to create a batch file for
> synthesis, but only if there is a FPGA express project. The foundation
> software does not make this project.
>
> The intention of this all is to use an other VHDL editor (Codewright) and to
> synthesise the project from there (bypassing the foundation GUI and version/
> revision philosophy). The design implementation is no problem, this is a
> long series of batch commands (check the fe.log and you can see all the
> batch commands for the implementation). The only thing is the syntax check
> and the synthesis and optimalisation.
>
> I think a lot of people can benefit from this.
>
> Mark van de Belt

--------------9C2F1FECA18BEBBABEB6079B
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;David
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;28560
fn:Dave Vanden Bout
end:vcard

--------------9C2F1FECA18BEBBABEB6079B--

Article: 19187
Subject: ALTERA EPC2 configuration problem
From: Volker Kalms <ea0038@uni-wuppertal.de>
Date: Fri, 03 Dec 1999 21:10:38 -0800
Links: << >>  << T >>  << A >>
Hi,

many thanks to all those who answered my enquiry!

The problem with the configuration of the EPC2 was solved by
upgrading from Altera MAXplusII v9.1 to MAXplusII v9.3.


Best Regards,

Volker
Article: 19188
Subject: Simple programmator for EP910
From: "Andrew Buckin" <ipm_grp@iptelecom.net.ua>
Date: Sat, 4 Dec 1999 07:28:29 +0200
Links: << >>  << T >>  << A >>

Simple programmator for EP910
--
IPM Group
Andrew Buckin  ipm_grp@i.kiev.ua
                          ipm_grp@iptelecom.net.ua


Article: 19189
Subject: Re: Synplify vs. FPGA Compiler II (v3.3)
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 04 Dec 1999 01:02:27 -0500
Links: << >>  << T >>  << A >>
Bruce Nepple wrote:
...snip...
> But all of the tools have their limitations and stress-points.  I guarantee
> that whatever tool you choose, if you are really picky about your results,
> you will be pissed at some point.  For example, Symplicity (at some point in
> the past) wouldn't deal well with greater than 12 state 1-hot machines, and
> Synopsys (at some point, and maybe still) decided they would change one of
> the states to a 0-hot state caus' they felt like it.  Many people would
> never notice since they passed functional vectors.

I was using FPGA Express under Foundation with the Xilinx XL4000 series
a while back. I found this problem with the one-hot encoding. It
actually used 15 FFs to implement 16 states. This gave me fits in my
simulation since it was a gate simulation and I could not predict which
state would get the 0-hot encoding. As I changed my state machine the
encoding would jump around on me. And this was after a lot of work to
get the thing to stop trying to use all 15 FFs to decode every state!!!

This is the big reason that I am not eager to use VHDL again. I spent
more time drawing schematics from the EDIF or XNF files to see what the
compilier had generated than I could ever have done to just input the
design in schematic in the first place! 

So now I am doing a 30 K gate FPGA in schematic. We will see which works
better for me in the end. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 19190
Subject: Re: Leonardo Spectrum Printing Problem
From: "Ptarmigan" <pt@colmer-clan.fsnet.co.uk>
Date: Sat, 4 Dec 1999 11:40:29 -0000
Links: << >>  << T >>  << A >>
There's nothing new about synthesis tools being tested one the market.
Don't think it's just the so-called budget tools like Leonardo Spectrum that
suffer in this way with terrible bugs, the high end tools are just as bad!

M.


John Doe wrote in message ...
>Leonardo Spectrum is a pretty good synthesis tool except for "1" thing....
>printing your schematics.
>
>I have asked their support team time and time again to fix the built in
>schematic viewer and for 20k+ a seat you think they would do that right???
>NO.  Instead the only reply that I got was I can either use the old
>schematic viewer that will not show higher levels of your design (i.e. you
>get 300 plus pages to print out) or use the new schematic tool and use cut
>and paste.  CUT AND PASTE!!! Has anyone seen the quality of the schematic
in
>the first place.  If you were to print that out in say Word you would get 1
>big black drawing.
>
>This is just a gripe.  I am disapointed that Exemplar and other companies
>cant seem to get their shit together and make some quality software (not
>just the engine but the user interface!!!).
>
>
>
>


Article: 19191
Subject: Re: Command line for FPGA Express
From: "Austin Franklin" <austin@dark99room.com>
Date: 4 Dec 1999 12:48:16 GMT
Links: << >>  << T >>  << A >>
I'd be interested in them...

Thanks!

Dave Vanden Bout <devb@xess.com> wrote in article
<384893F1.AC03EEDF@xess.com>...
> I created some makefiles in Win95 that run fe_shell and the Xilinx
implementation tools so I could do batch file compilations of VHDL into
.BIT and .SVF files.  I could write a small explanation and present them if
anyone is interested.  But I think there is a tool called xflow in M2.1
that gives you command-line control of the tools now.
> 
> 
> 
> Mark van de Belt wrote:
> 
> > Hello,
> >
> > I looked into this fe shell, and it is possible to create a batch file
for
> > synthesis, but only if there is a FPGA express project. The foundation
> > software does not make this project.
> >
> > The intention of this all is to use an other VHDL editor (Codewright)
and to
> > synthesise the project from there (bypassing the foundation GUI and
version/
> > revision philosophy). The design implementation is no problem, this is
a
> > long series of batch commands (check the fe.log and you can see all the
> > batch commands for the implementation). The only thing is the syntax
check
> > and the synthesis and optimalisation.
> >
> > I think a lot of people can benefit from this.
> >
> > Mark van de Belt
> 
Article: 19192
Subject: Re: CAN testing - Any CANbus cores out there?
From: tryggvem@my-deja.com
Date: Sat, 04 Dec 1999 15:41:56 GMT
Links: << >>  << T >>  << A >>
In article <3846DC36.F45F08DA@oxfordbromley.u-net.com>,
  jonathan@oxfordbromley.u-net.com wrote:
> "Raymond E. Rogers" wrote:
> > > >   I am organizing a CAN-2.0B testing procedure.
> <snip my suggestion>
> > This is certainly feasable and has some advantages
>
<snip>
> It occurs to me to ask whether anyone out there has a
> synthesisable VHDL core for a CAN controller.  It clearly
> wouldn't be cost competitive with commodity CAN parts
> for production, but it sure as hell would make this kind
> of diagnostic and special-purpose stuff far easier if you
> had a working controller core to start from that you could
> modify in an arbitrary way.
>
> I would be **very** interested in getting involved in
> any public-domain effort to realise this goal, as I
> have upcoming projects for which it would be rather
> useful.
>
<snip>
> Jonathan Bromley
>

Hello!

Seem like you are needing a parameterizable VHDL core with a flexible
test bench (or maybe moving some of the testbench features into the
core for test purpose). There is a core avalible, but the "public-
domain" issues are to be discussed. (At least some solutions can be in
that direction, but must be handle case by case).

It's available _now_ and here is the specification:
(If fits your requirements, please contact me by mail,
 Tryggve.Mathiesen123@XYZenator.se (123,XYZ SPAM filter to be removed
for more info)

ENATOR Elektroniksystem AB SWEDEN, has a CAN 2.0B CAN core build in
pure parameterizable VHDL.

FEATURES

 Working according to CAN specification 2.0B
 Easy-to-use serial interface makes it possible to develop a very
specific and optimized layer between the core and the user
application.
 Supports both standard and extended frame formats.
 Bit timing segment lengths configurable via generic parameters.
 Bus speeds up to 1 MHz supported. (Infact can be higher than 20 MHz,
but not within the standard)
 Many different system clock speeds supported using the Clock Enable
input.

_Core Specifics_
Device Family	XC4000E/EX / (Xilinx Spartan/Virtex / Altera
6K/8K/10K/APEX also possible)
Xilinx CLBs Used 255 (can be optimized if only 1 MHz is the requirement)
IOBs Used	 25
System Clock fmax	50 MHz (XC4000E/EX)
Device Features Used	Global Clocks

_Provided with Core_
Documentation		User guide
Design File Formats	VHDL source code
Constraint File		Standard
Verification Tools	VHDL Testbench
			VIEWlogic command scripts (files)
			ModelSim command scripts (files)


TESTBENCH

The provided testbench has tests for the following requirements in the
CAN Protocol:

________Protocol requirement___________Yes	No
_Transmission / Reception of frames_
Standard Data Frame with data		Y
Extended Data Frame with data		Y
Standard Data Frame with no data	Y
Extended Data Frame with no data	Y
Standard Remote Frame			Y
Extended Remote Frame			Y
_Error Types_
Bit Error				Y
Stuff Error				Y
CRC Error					N*
Form Error				Y
Ack Error				Y
Error Flags
Active					Y
Passive						N*
_Other_
Arbitration				Y
Automatic retransmission
after error or arbitration lost		Y

*Note: The table describes what tests the testbench automatically
performs.
 CRC Error and Passive Error Flags be tested by modifying the code in
different ways
 (changing the initial values of the CRC_Reg and the Receive and
Transmit Error Counters
 (REC and TEC). Many other things can be analyzed in the waveform.


The testbench uses three CAN Cores and a model for a Transceiver and a
Message Buffer
for each CAN Core. The first three testvectors are applied to each CAN
Core at the same time,
and therefore an arbitration process starts.
According to the priority between the messages, they are transmitted
one after another.
At the third message, a bit error occurs, which causes the transmitter
to send an error flag.
This flag causes a stuff error at the receivers, which puts them in an
error state.
After this, the message is retransmitted automatically.
When all three messages have been transmitted, the next three
testvectors are applied in
the same way. There is a possibility to test with different parameters:
 Time before sample point, TIME_BEFORE_SP.
 Time after sample point, TIME_AFTER_SP.
 System clock period, CLK_HI_LO. (The period will be 2*CLK_HI_LO).
 System clock divider, CLK_DIV, for the Clk_Enable signal.
 Physical delay time within the network, PROP_DELAY.
  The delay time from Tx to Rx will be 2*PROP_DELAY.

The testbench reports if the received message differs from the applied
stimuli,
and also if the simulated errors occur as expected.

//

Tryggve Mathiesen



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19193
Subject: Re: CAN testing - Any CANbus cores out there?
From: "Joseph Hlebasko" <hlebasko@indy.net>
Date: Sat, 4 Dec 1999 19:47:01 -0500
Links: << >>  << T >>  << A >>
I don't have the URL with me, but on the CAN mailing list a notice was
published about a "public domain" CAN core.  The organization was
European Space Agency (ESA).  The project name was "HuriCANe"
and was implemented with the purpose of studying the CAN controller.
I think if you do a search for ESA & Huricane you may find it.

Joseph Hlebasko

Jonathan Bromley <jonathan@oxfordbromley.u-net.com> wrote in message
news:3846DC36.F45F08DA@oxfordbromley.u-net.com...
> "Raymond E. Rogers" wrote:
> > > >   I am organizing a CAN-2.0B testing procedure.
> <snip my suggestion>
> > This is certainly feasable and has some advantages
> <snip>
> >  OTOH, it
> > is not as general and synchronization with the MAC layer would have to
> > be resolved.
>
> Yes indeed. - hence my comment about fooling the Rx.
>
> It occurs to me to ask whether anyone out there has a
> synthesisable VHDL core for a CAN controller.  It clearly
> wouldn't be cost competitive with commodity CAN parts
> for production, but it sure as hell would make this kind
> of diagnostic and special-purpose stuff far easier if you
> had a working controller core to start from that you could
> modify in an arbitrary way.
>
> I would be **very** interested in getting involved in
> any public-domain effort to realise this goal, as I
> have upcoming projects for which it would be rather
> useful.
>
> I've posted this also to comp.arch.fpga and comp.lang.vhdl
> (from sci.electronics.design) in the hope of exciting some
> interest.
>
> Jonathan Bromley


Article: 19194
Subject: Re: backup fifo's
From: Eric Crabill <crabill@xilinx.com>
Date: Sat, 04 Dec 1999 17:25:52 -0800
Links: << >>  << T >>  << A >>
Hi Rick,

It really depends on the implementation technology.
What you suggest is possible, but very difficult to
implement in an FPGA.

In order to do this, the FIFO would have to be
connected directly to the data bus pins without
using the output flip flops.  There would also be
some multiplexers between the two, because you
need to drive other stuff on the bus (like addresses).

At low speeds, this is possible, but 66 MHz PCI
requires a max clock to out of 6.0 ns.  If you add
up the global clock delay, the clock to out of the
FIFO, the routing and LUT based multiplexer, and
then the output delay of the pad, you will have a
hard time getting down to a 6.0 ns pin-to-pin clock
to out time.

Someone might argue that you can use a DLL or
PLL to reduce or eliminate the clock delay, but
this is also complicates the design:

1.  You have to be able to turn off the DLL or PLL
     when operating at 33 MHz, since the clock is
     allowed to change from 0 - 33 MHz at any time.
     A DLL or PLL will not work in this mode.

2.  You make the other "end" of the timing problem
     more difficult -- the setup specifications for the
     input signals.

Hope that helps,
Eric Crabill

Rickman wrote:

> I am not throughly familiar with the PCI bus spec, so I don't completely
> understand the timing issues here. But couldn't you solve this problem
> by just not popping the data off of the FIFO until you are sure the the
> transaction is complete? I don't know how your fifo is constructed, but
> all of the ones I have seen allow you to read the data without removing
> the data from the fifo.

Article: 19195
Subject: Re: Synplify vs. FPGA Compiler II (v3.3)
From: Greg Neff <gregneff@my-deja.com>
Date: Sun, 05 Dec 1999 02:26:58 GMT
Links: << >>  << T >>  << A >>
In article <3848AE73.B4146CD1@yahoo.com>,
  Rickman <spamgoeshere4@yahoo.com> wrote:

(snip)
> So now I am doing a 30 K gate FPGA in schematic. We will see which
works
> better for me in the end.
(snip)

Based on the comments that I am seeing, I have decided to delay jumping
into VHDL for a little while longer.  I'll try to spend some spare time
reading up on it.  I'm sure that sooner or later I'll get a customer
that demands VHDL, but then I'll make sure that I build *lots* of time
into the project, so that I can do a good job of the implementation.

BTW, I don't understand a one-hot state machine would be implemented
that that uses N-1 flip-flops.  If you need a wide ANDxBx gate to
decode the zero-hot state, then doesn't this break the definition of a
one-hot state machine?  Personally, I prefer to use binary register-
feedback state machines, with an output state decoder.  This keeps the
number of possible illegal states down to something reasonable, and
gives me an easy default reset state (0 when all register flip-flops
clear).


--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 19196
Subject: Re: Synplify vs. FPGA Compiler II (v3.3)
From: rk <stellare@NOSPAM.erols.com>
Date: Sat, 04 Dec 1999 22:08:11 -0500
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> In article <3848AE73.B4146CD1@yahoo.com>,
>   Rickman <spamgoeshere4@yahoo.com> wrote:
>
> (snip)
> > So now I am doing a 30 K gate FPGA in schematic. We will see which
> works
> > better for me in the end.
> (snip)
>
> Based on the comments that I am seeing, I have decided to delay jumping
> into VHDL for a little while longer.  I'll try to spend some spare time
> reading up on it.  I'm sure that sooner or later I'll get a customer
> that demands VHDL, but then I'll make sure that I build *lots* of time
> into the project, so that I can do a good job of the implementation.

that sounds like a good idea.  the learning curve is not insignificant.

=========================================

> BTW, I don't understand a one-hot state machine would be implemented
> that that uses N-1 flip-flops.  If you need a wide ANDxBx gate to
> decode the zero-hot state, then doesn't this break the definition of a
> one-hot state machine?  Personally, I prefer to use binary register-
> feedback state machines, with an output state decoder.  This keeps the
> number of possible illegal states down to something reasonable, and
> gives me an easy default reset state (0 when all register flip-flops
> clear).

i've seen several synthesizers (check version, phase of moon, etc.) that
use the n-1 states for a modified one-hot state machine.  for synplicity,
at least for the relatively recent version that i looked at, if you use the
output of the state that got encoded as all zero's it will shift back to
the n states, rather then the n-1 states, iirc.

using the all zero's state as a legal state does have some advantages; if
the flip-flops have only asynchronous clears (as some fpga architectures
do) then that saves some gates for that first flip-flop.  also, the first
stage is driven by a large NOR gate.  this "catches" illegal states and
gets the machine at least up and running again (dependent on some other
logic).  for case 1, when the one hot flop gets zonked, and you wind up
having all flip-flops cleared, then you immediately go into the state
following the 'home' state.  case 2) if you get more than one flop set,
then the nor logic will hold off setting the first flip-flop until they're
all cleared out.  this will also give you your easy default state.  and
make picking off particular states trivial, just take the output of the
flop. no decoding, no glitches as in the encoded state machine.

btw, synplicity has introduced a "safe" encoding mode for their fsm's which
will ensure that illegal states are detected and the machine is homed.  be
a tad careful, though, as the clear pulse is removed from the opposite edge
of the clock w.r.t. the rest of the state machine.

'rickman' has some good points, as i too spend a lot of time generating
schematics of things to see what the machine did.  of course, we used to do
that with programming languages too.  perhaps someday we won't need to
that.  but today, we do, as you can tell from the paragraph just above.

have a good evening,

------------------------------------------------------------------------
rk                                 The world of space holds vast promise
stellar engineering, ltd.          for the service of man, and it is a
stellare@erols.com.NOSPAM          world we have only begun to explore.
Hi-Rel Digital Systems Design      -- James E. Webb, 1968


Article: 19197
Subject: Re: Command line for FPGA Express
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 05 Dec 1999 12:03:29 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------76A8415FA16B8C7035E17567
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have posted the files + documentation in http://www.xess.com/fndmake.zip.  I have posted just the documentation in http://www.xess.com/fndmake.pdf.

The makefile and scripts will let you synthesize and implement CPLD and FPGA designs in a batchfile mode.  You need the fe_shell utility for running FPGA Express from a script.  You also need the UNIX-like make, cp, mv, echo, and cat command-line utilities that run in a DOS window.




Austin Franklin wrote:

> I'd be interested in them...
>
> Thanks!
>
> Dave Vanden Bout <devb@xess.com> wrote in article
> <384893F1.AC03EEDF@xess.com>...
> > I created some makefiles in Win95 that run fe_shell and the Xilinx
> implementation tools so I could do batch file compilations of VHDL into
> .BIT and .SVF files.  I could write a small explanation and present them if
> anyone is interested.  But I think there is a tool called xflow in M2.1
> that gives you command-line control of the tools now.
> >
> >
> >
> > Mark van de Belt wrote:
> >
> > > Hello,
> > >
> > > I looked into this fe shell, and it is possible to create a batch file
> for
> > > synthesis, but only if there is a FPGA express project. The foundation
> > > software does not make this project.
> > >
> > > The intention of this all is to use an other VHDL editor (Codewright)
> and to
> > > synthesise the project from there (bypassing the foundation GUI and
> version/
> > > revision philosophy). The design implementation is no problem, this is
> a
> > > long series of batch commands (check the fe.log and you can see all the
> > > batch commands for the implementation). The only thing is the syntax
> check
> > > and the synthesis and optimalisation.
> > >
> > > I think a lot of people can benefit from this.
> > >
> > > Mark van de Belt
> >

--------------76A8415FA16B8C7035E17567
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;David
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;28560
fn:Dave Vanden Bout
end:vcard

--------------76A8415FA16B8C7035E17567--

Article: 19198
Subject: Re: backup fifo's
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 05 Dec 1999 14:27:02 -0500
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> 
> Hi Rick,
> 
> It really depends on the implementation technology.
> What you suggest is possible, but very difficult to
> implement in an FPGA.
> 
> In order to do this, the FIFO would have to be
> connected directly to the data bus pins without
> using the output flip flops.  There would also be
> some multiplexers between the two, because you
> need to drive other stuff on the bus (like addresses).

I am not sure that I agree with the architecture constraints you are
describing. The issue is speed for sure. But I would certainly leave the
IOB FFs in so that the speed path becomes, detecting that the data was
accepted, incrementing the FIFO counter and clocking the data through
the muxes into the output FFs in one clock cycle. This may well not be
possible either. But the point is, removing the output FFs is not the
only way to work the problem. 


> At low speeds, this is possible, but 66 MHz PCI
> requires a max clock to out of 6.0 ns.  If you add
> up the global clock delay, the clock to out of the
> FIFO, the routing and LUT based multiplexer, and
> then the output delay of the pad, you will have a
> hard time getting down to a 6.0 ns pin-to-pin clock
> to out time.
> 
> Someone might argue that you can use a DLL or
> PLL to reduce or eliminate the clock delay, but
> this is also complicates the design:
> 
> 1.  You have to be able to turn off the DLL or PLL
>      when operating at 33 MHz, since the clock is
>      allowed to change from 0 - 33 MHz at any time.
>      A DLL or PLL will not work in this mode.

But can't this be selected ahead of time. At 33 MHz you have much more
time to process the signals eliminating the need for the PLL clock. At
66 MHz the clock rate is fixed IIRC. Or do they allow a dithered clock
at 66MHz? 

 
> 2.  You make the other "end" of the timing problem
>      more difficult -- the setup specifications for the
>      input signals.

I see the problem. This is the approach I would take, but it obviously
has the same problem, just on the other end of the timing chain. 

 
> Hope that helps,
> Eric Crabill

Yes, it seems to be an internal timing limitation because of the
pipelining required. I have never worked with PCI at 66MHz, so I didn't
realize that you were running at those speeds.

Article: 19199
Subject: hobbyist friendly pld?
From: Dan Rymarz <m261981@boeing.com>
Date: Sun, 5 Dec 1999 21:24:34 GMT
Links: << >>  << T >>  << A >>
Hello all,

I am looking for a programmable logic technology I can use that
also has a free+permanant (not 30 day trial) compiler available, that
uses JTAG or similar few-wire (4 for jtag etc.) programming mode.  I
don't need a large gate count.  It seems like the  big devices need big
software, and the small ones need special programming hardware.  Does
anyone know where this holy grail of digital hobbyist devices exists -
free s/w and simple h/w?  

                                                      Thanks,
                                                             Dan


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
2017JanFebMarApr2017

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