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 25875

Article: 25875
Subject: Re: CORDIC COS/SIN with FPGA implementation
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 24 Sep 2000 01:40:59 -0400
Links: << >>  << T >>  << A >>
"default@user.com" wrote:
> 
> > Sounds like you missed the mark on the shifter.  An 8 bit barrel shift (fully
> > populated) should occupy 24 4-LUTs and should be 3 levels of logic deep.  You
> > have to implement it, the tools will not infer the correct structure by
> > themselves.
> 
> Hi, the Xilinx XC4xxx library (the library that comes with Foundation
> 1.5) includes an 8-bit barrel shifter.  I played around with this macro,
> and have concluded its more like a 'bit rotater.'  Opening the macro in
> the schematic editor indeed shows 24 2:1 muxes, arranged as 8bits x
> 3deep.
> 
> The block in question, however, is an ARITHMETIC shifter.  I guess you
> could call it a barrel-shifter + sign-extender.  I did a bit of
> preliminary work writing structural verilog (before, I had a for-loop
> inside an always@() block), the structural verilog implementation
> ultimately synthesized to the same bloated FPGA map.
> 
> I'll go and try it again, though.  My structural verilog did not use any
> kind of 'barrel' structure (bit-rotate), so that's the next thing to
> try.

You might try the equivalent of three sequential IF (or the verilog
equivalent) structures. Each one should be controlled by one bit of the
shift size vector. The output of each level of IF should feed the input
of the next level. A FOR loop will give you N levels of 2 to 1 muxes
without using the optimization available from sharing levels. 

If you need more speed, you can pipeline the muxes by registering each
level. 

if (sel(0) = '1') then
  stageA <= input(7) & input(7 downto 1);
else
  stageA <= input(7 downto 0);
end if;

if (sel(1) = '1') then
  stageB <= stageA(7) & stageA(7) & stageA(7 downto 2);
else
  stageB <= stageA(7 downto 0);
end if;

if (sel(2) = '1') then
  stageC <= stageB(7) & stageB(7) & stageB(7) & stageB(7) & stageB(7
downto 4);
else
  stageC <= stageB(7 downto 0);
end if;

Output <= stageC;

This is VHDL, but you get the idea. Three levels, 8 muxes at each level,
24 4LUTs.


-- 

Rick 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

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

Internet URL http://www.arius.com
Article: 25876
Subject: Re: CORDIC COS/SIN with FPGA implementation
From: Ray Andraka <ray@andraka.com>
Date: Sun, 24 Sep 2000 06:12:58 GMT
Links: << >>  << T >>  << A >>
A barrel shift and a programmed arithmetic shift are the same circuit other than
the connections at the ends of the shift.  In the barrel inputs that would come
off one end are connected from the other end, in the arithmetic, they are
connected to the sign, and in a logical to zero.  It would be a fairly trivial
modification if you could get into the source on the cores.

"default@user.com" wrote:
> 
> Hi, the Xilinx XC4xxx library (the library that comes with Foundation
> 1.5) includes an 8-bit barrel shifter.  I played around with this macro,
> and have concluded its more like a 'bit rotater.'  Opening the macro in
> the schematic editor indeed shows 24 2:1 muxes, arranged as 8bits x
> 3deep.
> 
> The block in question, however, is an ARITHMETIC shifter.  I guess you
> could call it a barrel-shifter + sign-extender.  I did a bit of
> preliminary work writing structural verilog (before, I had a for-loop
> inside an always@() block), the structural verilog implementation
> ultimately synthesized to the same bloated FPGA map.
> 
> I'll go and try it again, though.  My structural verilog did not use any
> kind of 'barrel' structure (bit-rotate), so that's the next thing to
> try.
> 

-- 
-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  or http://www.fpga-guru.com
Article: 25877
Subject: Re: memory interface trouble...
From: "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Sun, 24 Sep 2000 09:04:10 +0200
Links: << >>  << T >>  << A >>
Hi,

"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
news:39CD6787.2A93CB66@earthlink.net...
>
...

> What you descibe is not tristate, but rather a weak latching action ( we
> at Xilinx call it "weak keeper") which prevents floating inputs and
> undefined levels, but does not guarantee a specific logic level. As you
> describe it, the pin becomes either a 1 or a 0, depending on the last
> drive, internal or external.
>
> Peter Alfke
>

That sounds to be perhaps the better description for this state,
but I wouldn't believe, that the Infineon processor could not
drive against this "weak keeper", as you don't need a lower
resistor than 100KOhm to change the level at the I/O Pin...

It's curious, that the C167 seems to ignore, that he has to
start it's bootstrap loader...

CU, Carlhermann


Article: 25878
Subject: Paranoid...
From: "Gary Watson" <gary2@nexsan.com>
Date: Sun, 24 Sep 2000 18:39:00 +0100
Links: << >>  << T >>  << A >>

I'm doing a board with a Xilinx Spartan II (XC2S150) and have provided
places for both a XC17S150XL and a XC18V01S20 config prom.  Am I being
overly paranoid?

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com





Article: 25879
Subject: Re: Xilinx Student Edition 2.1i with "Digital Design:Principles and Practices"
From: "Jan Gray" <jsgray@acm.org>
Date: Sun, 24 Sep 2000 18:17:49 GMT
Links: << >>  << T >>  << A >>
"Guest Internet User" <INVALID@INVALID.NET> wrote in message
> Does anyone know if this is the same software as the standalone Xilinx
> Student Edition 2.1i by Prentice Hall?  Seems like the standalone
> package is hard to find.

See http://vig.prenhall.com/academic/product/1,3411,0130289078,00.html.

You can order a copy of this standalone software from fatbrain.com, which
reports it to be "in stock".  Amazon.com says "4-6 weeks".  Xess.com says
"in stock".  ISBN: 0-13-028907-8.

The significantly-cheaper $55 Student Ed. 2.1i appears to target the XCV50
and therefore the bit-compatible XC2S50 (about $13 q1), making Virtex
development much more accessible to budget conscious designers.  And it's
perfectly adequate for developing and testing reusable Virtex IP cores,
including processors, for subsequent integration into larger Virtex/E/II
designs (which require the professional tools).

We're in for lots of fun -- and some astonishing student projects.  See
www.fpgacpu.org/teaching.html.  Hats off to Xilinx and Prentice-Hall.
Thanks to products like this, I think we will witness more new processor,
signal processing, and SoC designs in the next two years than in the entire
history of computers.

Alas, unlike the 1.3 and 1.5 editions, the 2.1i edition does not seem to
bundle the "Practical Xilinx Designer Lab Book" by Dave Vanden Bout.  That
book, together with an XS40 board and XSTOOLS, is a great, Xilinx
tools-focused, hands-on introduction to digital design with FPGAs -- which
is why I built my tutorial works to that platform.

Jan Gray
Gray Research LLC



Article: 25880
Subject: Re: MAPLD
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 24 Sep 2000 18:24:08 GMT
Links: << >>  << T >>  << A >>
Hi, I'll be there. Even on a panel discussion about "PLD Hardware and Software in
High-Rel, High-Safety, and High-Security Mission-Critical Environment" on
Wednesday. What a mouthful!
See ya there
Peter Alfke

Ray Andraka wrote:

> Hey Peter,
>
> Are we going to see you at MAPLD this week, or are you weaseling out of this one
> too?  I'll be there!
>
> Peter Alfke wrote:
> >
> > Carlhermann Schlehaus wrote:
> >
> > ? ALTERA has weak pull up resistors on their I/O Pins, which
> > ? are active when the FPGA is not configured (C167CR could be
> > ? configured by Bootstrap Loader) and which are activated for
> > ? tri-state I/O Pins.
> > ? I've tested them by trying to force 5V and 0V with a 100KOhm
> > ? resistor. The pin stays on the voltage, which was applied
> > ? by this 100K resistor, thus I really would say these Pins are
> > ? tristated...
> >
> > What you descibe is not tristate, but rather a weak latching action ( we
> > at Xilinx call it "weak keeper") which prevents floating inputs and
> > undefined levels, but does not guarantee a specific logic level. As you
> > describe it, the pin becomes either a 1 or a 0, depending on the last
> > drive, internal or external.
> >
> > Peter Alfke
>
> --
> -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  or http://www.fpga-guru.com

Article: 25881
Subject: Re: memory interface trouble...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 24 Sep 2000 18:27:38 GMT
Links: << >>  << T >>  << A >>


Carlhermann Schlehaus wrote:

> That sounds to be perhaps the better description for this state,
> but I wouldn't believe, that the Infineon processor could not
> drive against this "weak keeper", as you don't need a lower
> resistor than 100KOhm to change the level at the I/O Pin...
>
> It's curious, that the C167 seems to ignore, that he has to
> start it's bootstrap loader...
>

Obviously, the uP can drive successfully against this.
But what if the uP uses this signal just as an input?

Peter Alfke


Article: 25882
Subject: Re: memory interface trouble...
From: "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Sun, 24 Sep 2000 23:03:51 +0200
Links: << >>  << T >>  << A >>
Hi Peter,

"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
news:39CE4798.CBDDB75E@earthlink.net...
>
>
...
>
> Obviously, the uP can drive successfully against this.
> But what if the uP uses this signal just as an input?

All Pins, which are sampled at startup by the uP to
determine the user-defined startup or bus mode are
terminated with pull-ups or pull-downs...
Thus I'm meanwhile thinking, there is another pin
involved, which is not mentioned in the databook of
the uP.

CU, CS




Article: 25883
Subject: 20 bit to 64 bit bus conversion
From: "Anoop Nannra" <anoop.nannra@sympatico.ca>
Date: Mon, 25 Sep 2000 01:46:23 GMT
Links: << >>  << T >>  << A >>
Hi All,

I'm trying to figure out a buffering strategy for doing a 20 bit to 64 bit
bus conversion and vice versa.

I've come up with something simple like storing 32 20bit transactions and
then doing a copy to a 640 bit register and then performing 10 64bit
transactions.  Unfortunately I don't like this solution as it's not that
elegant.  Does anyone out there kow of a better way to do this ?

TIA

Anoop


Article: 25884
Subject: Re: 20 bit to 64 bit bus conversion
From: David Forbes <dforbes@azspamnet.com>
Date: Sun, 24 Sep 2000 21:02:25 -0700
Links: << >>  << T >>  << A >>
In article <P7yz5.290839$1h3.6391493@news20.bellglobal.com>, "Anoop 
Nannra" <anoop.nannra@sympatico.ca> wrote:

> Hi All,
> 
> I'm trying to figure out a buffering strategy for doing a 20 bit to 64 bit
> bus conversion and vice versa.
> 
> I've come up with something simple like storing 32 20bit transactions and
> then doing a copy to a 640 bit register and then performing 10 64bit
> transactions.  Unfortunately I don't like this solution as it's not that
> elegant.  Does anyone out there kow of a better way to do this ?
> 
> TIA
> 
> Anoop
> 
> 

Anoop,

There are several ways to proceed. Which one to choose depends on the 
data rate relative to device clock speed.


If the incoming word rate is < 1/20 the device's clock speed, then you 
can serialize the data in a 20-bit shift register and shift it into a 
64-bit shift register. Double buffering will be needed on each shift 
register, but this is a very small circuit.

You can deal with data up to 1/4 the device's clock speed by using a 
4-bit-wide shift register for the above trick, loading the 4 bits in 
parallel into a 5-nibble-long input shift register feeding a 
16--nibble-long output shift register that feeds a 64-bit wide output 
holding register.

If your input rate is faster than that, then a 64-bit wide 5-input 
multiplexer with the proper nibble steering logic is required. Triple 
buffering of the output is needed - one 64-bit register to hold the last 
complwted output word, and a double 64-bit construction register since a 
20-bit word may straddle two 64-bit words. If there is not an extra 
clock period available to do the straddling, then yo need more mux bits 
for these cases.

The control for this is a state machine that sequences thru the output 
registers in 20-bit steps. It controls which 20 bits of the two 
construction registers are enabled to receive data, and tells the muxes 
which input data goes into each 4-bit nibble of these registers.

There are 16 states in this machine, assuming that input data changes on 
every clock.

--David Forbes
Tucson AZ

Change spamnet to starnet before replying.
Article: 25885
Subject: Re: 20 bit to 64 bit bus conversion
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 25 Sep 2000 04:18:56 GMT
Links: << >>  << T >>  << A >>
Hi.

I'm not sure what exactly you're trying to do, but I'll take a stab at it.

I'm assuming that you can't afford to waste any write operations to the 20-
bit bus.  ie, When you write (4x20=80) bits using 4 cycles, you need the 
bottom 64 bits to go to cycle n of OUT(63..0), and then the remaining 16 
bits to go to cycle n+1 of OUT(15..0)?

I would do the following.
Have a small state machine/counter at the input stage that tells you what 
20-bit write you're on.  That counter resets itself once you've written 320 
bits, which is 16 cycles.  This fits nicely into a 4-bit counter. 

Use a 64-bit register, and the 4 bits of the counter to control an input 
mux, and the write enables.

Consider (Where OUT is your 64-bit register):

Counter Value  OUT Bits
0              19..0
1              39..20
2              59..40
3              63..60, 15..0
4              35..16
5              55..36
6              63..56, 11..0
7              31..12
8              51..32
9              63..52, 7..0
A              27..8
B              47..28
C              63..48, 3..0
D              23..4
E              43..24
F              63..44

This gives you 16 different write enables, one for every 4 bits of OUT.

Then, for example, the Write enable for OUT(3..0) is when your counter is 
equal to [0, 3, 6, 9, or C].  The WE for OUT(40..43) is when the counter is 
equal to [2, 5, 8, B, or E].

The input MUX will work much the same way, using the counter to control the 
input to each 4-bit block of your OUT register.  For example, consider 
OUT[3..0].  This section of your output register gets the following data at 
the following counter values:

Counter  Bits to OUT(3..0)
0        IN(3..0)
3        IN(7..4)
6        IN(11..8)
9        IN(15..12)
C        IN(19..16)

The other values of the counter don't matter for bits OUT[3..0], so 
optimize your counter accordingly.

Hope this helps.

-Kent





anoop.nannra@sympatico.ca (Anoop Nannra) wrote in 
>I'm trying to figure out a buffering strategy for doing a 20 bit to 64 bit
>bus conversion and vice versa.
>
>I've come up with something simple like storing 32 20bit transactions and
>then doing a copy to a 640 bit register and then performing 10 64bit
>transactions.  Unfortunately I don't like this solution as it's not that
>elegant.  Does anyone out there kow of a better way to do this ?
>
>TIA
>
>Anoop
>
>
>

Article: 25886
Subject: FPGA for PCM coded DTMF transmission?
From: "Neo Wei Thiam" <neowt@cet.st.com.sg>
Date: Sun, 24 Sep 2000 21:58:04 -0700
Links: << >>  << T >>  << A >>
I am currently using 2 chips to produce a PCM coded DTMF stream and was trying to replace it with a Xilinx fpga that was already in the design for other reasons.

My solution was to store the pre-calculated PCM code on ROM and tasked the CPU to load up a series of 8-bit PCM registers on FPGA before initiating the transmission.  The FPGA will continously loop through the registers to transmit the PCM code.

However I realised it took about 50% of the FPGA resources to implement a sequence of 50 registers of the 40k gate FPGA. This is much lower than the available 3k RAM available.  

Is this the norm?  If so, how can we get 3k RAM out of the FPGA?
I implemented the design in VHDL and inferred the RAM using array.

Regards,

Neo Wei Thiam
Article: 25887
Subject: Re: Virtex 1800 series ISP proms
From: "Peter Schulz" <p.schulz@signaal.de>
Date: Mon, 25 Sep 2000 11:25:52 +0200
Links: << >>  << T >>  << A >>
instead of using 31i sp2 you also can download the JTAG programmer
of the latest WEBpack - Tools

Peter

chadlamb@my-deja.com schrieb in Nachricht <8qgli1$m3$1@nnrp1.deja.com>...
>Make sure you are using the 31i, sp2 or later.  We came across the same
>problem.  They had screwed up the software.  We didn't have to do
>anything to pins to get it to work, just update your software.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.


Article: 25888
Subject: Dual monitor display possible with modelsim on a PC?
From: Nial Stewart <nials@sqf.hp.com>
Date: Mon, 25 Sep 2000 11:29:36 +0100
Links: << >>  << T >>  << A >>
I'm about to order bits to build a PC for FPGA simulation/
compilation/PAR.

I'm going for a 750M Althlone Thunderbird on an Asus A7V motherboard
with
256M memory (to start), a 15G IBM ATA100 hard drive with a
Yamaha 8x8x24 CD-WR for project documentation.

Any comments?

I've been thinking about buying a Matrox G400 video card with
dual output as I was thinking that it would be very handy to
be able to view a modelsim wave window on one monitor, with
all the other modelsim windows on another one.

Has anyone tried this? I know that windows98 supports dual
monitors, but does the application software have to support 
them too, or does it jut create more desktop on the second one?

Thanks for any advice.

Nial Stewart.
Article: 25889
Subject: Re: FPGA for PCM coded DTMF transmission?
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Mon, 25 Sep 2000 12:50:42 +0200
Links: << >>  << T >>  << A >>
You might want to check out the new FPSLIC (AVR+RAM+Peripherals+FPGA).
You have 40k gates of FPGA.
In addition, you have 12kx8 SRAM accessible from the FPGA.
On top of that you have 2kB distributed SRAM
--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden

"Neo Wei Thiam" <neowt@cet.st.com.sg> wrote in message
news:ee6e179.-1@WebX.sUN8CHnE...
> I am currently using 2 chips to produce a PCM coded DTMF stream and was
trying to replace it with a Xilinx fpga that was already in the design for
other reasons.
>
> My solution was to store the pre-calculated PCM code on ROM and tasked the
CPU to load up a series of 8-bit PCM registers on FPGA before initiating the
transmission.  The FPGA will continously loop through the registers to
transmit the PCM code.
>
> However I realised it took about 50% of the FPGA resources to implement a
sequence of 50 registers of the 40k gate FPGA. This is much lower than the
available 3k RAM available.
>
> Is this the norm?  If so, how can we get 3k RAM out of the FPGA?
> I implemented the design in VHDL and inferred the RAM using array.
>
> Regards,
>
> Neo Wei Thiam


Article: 25890
Subject: Re: Dual monitor display possible with modelsim on a PC?
From: "Gary Watson" <gary2@nexsan.com>
Date: Mon, 25 Sep 2000 12:16:30 +0100
Links: << >>  << T >>  << A >>

I have a dual-screen Matrox, and Foundation 3.1i works mostly, but some of
the drop-down boxes don't work if you have it on the secondary display.
Generally, I find that most software behaves ok, but things like OrCAD have
some surprising behaviors.  If you have a problem, it's best not to maximize
its window -- software seems to  jump to the conclusion that it "owns" the
entire display subsystem when maximized.

Make sure you download the latest drivers from the Matrox web site.  The
ones on the CD, straight from Matrox, are over a year old!

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com


"Nial Stewart" <nials@sqf.hp.com> wrote in message
news:39CF2910.2DB1EC75@sqf.hp.com...
> I'm about to order bits to build a PC for FPGA simulation/
> compilation/PAR.
>
> I'm going for a 750M Althlone Thunderbird on an Asus A7V motherboard
> with
> 256M memory (to start), a 15G IBM ATA100 hard drive with a
> Yamaha 8x8x24 CD-WR for project documentation.
>
> Any comments?
>
> I've been thinking about buying a Matrox G400 video card with
> dual output as I was thinking that it would be very handy to
> be able to view a modelsim wave window on one monitor, with
> all the other modelsim windows on another one.
>
> Has anyone tried this? I know that windows98 supports dual
> monitors, but does the application software have to support
> them too, or does it jut create more desktop on the second one?
>
> Thanks for any advice.
>
> Nial Stewart.
>




Article: 25891
Subject: Re: Alliance 3.1i CAE Libs install hangs under Solaris
From: petter@scimba.dolphinics.no
Date: 25 Sep 2000 10:36:58 -0100
Links: << >>  << T >>  << A >>
Paul Smith <ptsmith@indiana.edu> writes:

> These problems and more are covered on the Xilinx support web site. 
> They have a different installer you can download, and mention they will
> not use the web based installer for future versions.   Good!!!!!!

I'm very glad to here that! I can't see why they want the customers to
open up security holes and require netscape, java, and javascript only
to extract a few files.

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 25892
Subject: Re: Category : tri state data bus
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Mon, 25 Sep 2000 16:19:37 +0200
Links: << >>  << T >>  << A >>
Hi Tomek,

Can you describe how you did the 'implementation'? How did you write
your source
code since your test bench works only for behavioural simulation? (Did
you
use behavioural synthesis??)

If you write your source code at RTL level it should be very easy to
write a
test bench that works without change both for the source code and the
back annotated
netlist - just perform r/w operations on the data bus, maybe with a
couple of timing
probes in the test bench if you need that.

Good luck,
Johan P, Sweden

Tomek wrote:
> 
> Hello,
> 
> I have a problem with simulation of model after implementation. It's a model of tri state data bus in verilog. The code is below:
> 
> module DataBusBuffer(D,D_IN,READ_C0,READ_C1,READ_C2,WRITE_2_C0,WRITE_2_C1,WRITE_2_C2,WRITE_2_CWR,D_OUT);
> 
> inout [7:0] D;
> input [7:0] D_IN;
> input READ_C0;
> input READ_C1;
> input READ_C2;
> input WRITE_2_C0;
> input WRITE_2_C1;
> input WRITE_2_C2;
> input WRITE_2_CWR;
> //----------------------------------DECLARATION of OUTPUTS-----------------------------------------
> output [7:0] D_OUT;
> //------------------TRANSFER from INTERNAL BUS to DATA BUS----------------------------------------------
> assign D=(READ_C0 || READ_C1 || READ_C2) ? D_IN : 8'bz;
> //------------------TRANSFER from DATA BUS to INTERNAL BUS----------------------------------------------
> assign D_OUT=(WRITE_2_C0 || WRITE_2_C1 || WRITE_2_C2 || WRITE_2_CWR) ? D : 8'bz;
> 
> endmodule
> 
> I do not know how write a testbench into model after implementation.I have a testbench, but it works only for behawioral simulation.
> 
> Please about help
> 
> P.S If you can help me, I will send you the files, because i do not know how attach the files into post:
> 
> data_bus_im.v -model after implement
> data_bus_im.sdf
> data_bus_s.v - model after synthesis
> data_bus.v -model behavioral
> tb_data_bus.v - testbench
> 
> Tomek

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25893
Subject: Re: Is correct code?
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Mon, 25 Sep 2000 16:43:55 +0200
Links: << >>  << T >>  << A >>
Tomek,

I think you are posting your questions to the wrong news group. Typical
language
questions like yours will get the best answers at comp.lang.verilog.

/Johan P :)

Mujtaba Hamid wrote:
> 
> It seems that D is the bi-directional port and D_IN and D_OUT are busses interfacing with the port D.
> If that is the case, the correct code would be
> 
> inout [7:0] D;
> input CNTRL;
> 
> wire D_IN;
> reg D_OUT;
> 
> assign D = CNTRL ? D_OUT : 8'bZ; -- 3 stated output
> 
> always @ (CNTRL or D)
> if (CNTRL = '0')
>   D_IN <= D;
> 
> Mujtaba
> 
> Tomasz Brychcy wrote:
> 
> > Hello,
> >
> > I have written a model of tri state data bus:
> >
> > ports:
> >
> > inout [7:0] D;
> > input [7:0] D_IN;
> > input CNTRL;
> > output [7:0] D_OUT;
> >
> > assign D=(CNTRL) ? D_IN ? 8'bz; //write
> > assign D_OUT=(~CNTRL) ? D ? 8'bz; //read
> >
> > When I simulate the model (timing simulation) results are not correct. Behavioral simulation (before and after synthesis ) is correct. What I should do? Maybe testbench is wrong?
> >
> > I request for reply
> >
> > Tomek

-- 
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25894
Subject: Re: Multi-Arch, Moderately High performance VHDL FPGA Code?
From: Johan Petersson <Johan.Petersson@uab.ericsson.se>
Date: Mon, 25 Sep 2000 17:02:12 +0200
Links: << >>  << T >>  << A >>
Hi Robert,

I have done several "successful" transports between different FPGA
architectures/
providers without changing the source code, reaching "reasonebly high
performance"
(170 MHz in a xcv highest speedgrade many levels of logic). I changed
nothing in
the source (the change was from some Altera device) but I did a couple
of things
with the synthesis script.

Wait... the answer is NO, because I have not written the source myself
for any
of those transports - i have only done back end of the design :)

/Johan P


Robert Posey wrote:
> 
> Dear Gentle Persons,
> 
> Has anyone successfully written VHDL code for large FPGA's that is transportable
> without modification between Xlinx, Altera Etc. I looking for someone who
> has actually successfully complete the process.  To get reasonable high
> performance, its seems almost everyone uses arch. specific components, which
> likely won't match up at least between companies.  Has anyone tried this
> lately.  By Moderately high performance I mean a FPGA more than 70% utilized,
> and operating at speed levels that require one of the faster speed grades for
> a given arch.
> 
> Muddy
Article: 25895
Subject: Using the xilinx "pull-up to 5V" in VHDL
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Mon, 25 Sep 2000 17:46:59 +0200
Links: << >>  << T >>  << A >>
Hello,

I need to interface a Spartan 40XL with a 5V CMOS (not TTL compatible,
sigh...)
I've seen on the Xilinx web an application note (vtt002.pdf) where they use
a pull-up resistor to 5V and use the input to put the output in 3 state when
it has reached a 3.3V 1 level. (not very clear description. i't better
explained in the AN)

How can I use this in VHDL? I use this output as a 3-state bus.
Should I instanciate an OBUFT gate or is there a more clever way to do this?

Thanks

Marc Battyani



Article: 25896
Subject: Re: 20 bit to 64 bit bus conversion
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 25 Sep 2000 12:30:51 -0400
Links: << >>  << T >>  << A >>
I also do not completely understand what you are doing, but this sounds
a little like a bit packing function I had to design once. Your case is
a bit simplified by the fact that they two data sizes have a common
divisor of 4. 

You can construct a barrel shifter to rotate the 20 bit word into a
second 20 bit word. The second 20 bit word is applied to each 20 bit
chunk of a 64 bit register. The remaining four bits of the 64 bit
register pickup the 4 LSBs of the second 20 bit word. 

I know this sounds confusing, but it gets worse. I'll try a diagram.

        Rotate                Pack           Delay          Hold
                        4   _________        ______        _______
                     ||=/=>|         |      |      |      |       |
                     || 20 |         |  16  |      |  16  |       |
                     ||=/=>|         |==/==>| Reg  |==/==>|   64  |
       _________     || 20 |         |      |      |      |  Bit  |
      |         |    ||=/=>|   64    |      |      |      |  Reg  |
  20  | Barrel  | 20 || 20 |   Bit   |      |______|      |       |  64
==/==>| Shifter |=/=====/=>|D  Reg   |                    |      
|==/==>
      |         |       16 |         |         48         |       |
      |_________|    ===/=>|CE       |=========/=========>|       |
       _________    ||     |_________|                    |_______|
      |         |   || 
      |  Enable |====
      |_________|

A counter and decoder keeps track of where the data is being stored into
the packing register. The decoder enables 5, 4-bit sections of the 64
bit register on every 20 bit word that is written. When the last word is
written to the 64 bit register the holding register is clocked. On the
last word some bits may be written around the top/bottom so you need to
add a delay register to save the bits that will be overwritten. 

This will give you a 64 bit word on every 3 or 4 writes from the 20 bit
bus. This should be much less hardware than a 640 bit register and
should also reduce your latency a great deal. 



Anoop Nannra wrote:
> 
> Hi All,
> 
> I'm trying to figure out a buffering strategy for doing a 20 bit to 64 bit
> bus conversion and vice versa.
> 
> I've come up with something simple like storing 32 20bit transactions and
> then doing a copy to a 640 bit register and then performing 10 64bit
> transactions.  Unfortunately I don't like this solution as it's not that
> elegant.  Does anyone out there kow of a better way to do this ?
> 
> TIA
> 
> Anoop

-- 

Rick 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

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

Internet URL http://www.arius.com
Article: 25897
Subject: Re: Multi-Arch, Moderately High performance VHDL FPGA Code?
From: Robert Posey <muddy@raytheon.com>
Date: Mon, 25 Sep 2000 12:21:21 -0500
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> The short answer is yes.  You can often get reasonably high performance using
> only the constructs that a decent synthesis tool generates.  All that infers is
> that you have written your code in such a way that it doesn't pile many levels
> of combinatorial stuff between registers.  For example, A simple shift register
> will pretty much run at the max speeds of the fpga regardless of the
> architecture.
> 
> Filling up a big device is not hard either, **especially** if you don't use the
> device features in your code.
> 
> So, neither of these benchmarks are truely a measure of optimality for an FPGA
> design.  I'm not sure what you would use as an objective metric.  Perhaps the
> ratio of equivalent gates (in your design) to marketing gates.  

I wasn't implying it was, I was trying to insure that the design transferred 
between companies was one that stressed the abilities for the two different
but roughly equal FPGA arch.  

In most of the Military systems, we try and
keep the first release of a FPGA below 75%(or even better 50%) of total
capacity to allow significant changes without relaying out the board.  In
our business the potential cost of relaying out the board is only spread
over 20-2000 copies of a board.  Plus there is the fact that we might have
to make changes 10 years from now, and if we have to replace the board 
it will be a complete redesign due to parts that aren't made anymore.



> FOr the speed grade comment, Having to use one of the faster speed grade parts
> is not what I'd consider a badge of honor, A true mark of excellence is getting
> a fast design to meet timing in a slow speed grade part.  

I included the speed grade comment to attempt to insure that people wouldn't
give
examples of 20 Mhz designs in a 200 Mhz part.  If the synthesis tool works at
all, straight VHDL should work fine unless there are hidden performance 
requirements.  Of course the best designs will minimize the speed requirements
for a given task, but that wasn't the point.

> When it comes down to the bottom line, I guess the measurement could be is the
> customer happy with the price and performance.  That's what it's all about isn't
> it?
>
In the End, though we usually work to contractual requirements that we have to
meet or explain why.

Muddy
Article: 25898
Subject: Re: Xilinx and CD databooks (rant)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 25 Sep 2000 18:45:52 +0100
Links: << >>  << T >>  << A >>


Bill Blyth wrote:

> I would second the point on raw pinout data. This would beat copying the
> stuff from the pdf, reformatting it and subsequent symbol generation and
> checking.
>

This would indeed be great but after asking this of just about every device
manufacturer on the planet over the last 10 years I've come to the conclusion
that its an exercise in futility.
For the FPGA/CPLD manufacturers there's really no excuse since this info has to
be available for the place/route tools.


Article: 25899
Subject: Re: FPGA for PCM coded DTMF transmission?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 25 Sep 2000 14:36:39 -0400
Links: << >>  << T >>  << A >>
It is likely that your resource count was high because you were using FF
based registers instead of the LUT based RAM. A LUT will give you 16
bits of storage instead of one bit in a FF. To get deeper memory, you
can either use LUTs as muxes or use the T-bufs as tristate buffers onto
the long lines. Either way works. 

If you are desiging 50 registers, 4 banks of LUTs can be combined to
give you a 64 bit memory. If they are 8 bits wide, you are looking at
either 16 CLBs for a Tbuf based design or 28 CLBs for a mux based
design. To get either of these, you will need to instantiate the memory
or at least look at some sample code from Xilinx. 

There are RAM primatives for VHDL and I believe there are ROM primatives
that let you define the contents as part of the VHDL design if that is
better. But I guess your micro loads the values for the tones when it
decides which tones to output. 

This is all assuming you are working in a 4K series of Xilinx devices.
The Virtex parts have block memory that can do this in one block. 



Neo Wei Thiam wrote:
> 
> I am currently using 2 chips to produce a PCM coded DTMF stream and was trying to replace it with a Xilinx fpga that was already in the design for other reasons.
> 
> My solution was to store the pre-calculated PCM code on ROM and tasked the CPU to load up a series of 8-bit PCM registers on FPGA before initiating the transmission.  The FPGA will continously loop through the registers to transmit the PCM code.
> 
> However I realised it took about 50% of the FPGA resources to implement a sequence of 50 registers of the 40k gate FPGA. This is much lower than the available 3k RAM available.
> 
> Is this the norm?  If so, how can we get 3k RAM out of the FPGA?
> I implemented the design in VHDL and inferred the RAM using array.
> 
> Regards,
> 
> Neo Wei Thiam

-- 

Rick 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

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

Internet URL http://www.arius.com


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