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 75125

Article: 75125
Subject: Re: PCBs for modern FPGAs.
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 26 Oct 2004 11:21:47 -0700
Links: << >>  << T >>  << A >>
Kenneth,
Comments added.
"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message
news:10ns44e65o5gp31@news.supernews.com...
>
> Symon,
>
> What are the speeds of your clocks and signals both within your FPGA and
> external?
I use 600+MHz clocks and > 600+Mbit data to and from the FPGA. I always use
the 'divide-by-two' DCM thing and DDR IOBs for this. There's also 2.5
GHz/Gbps in some places on some boards, not to the FPGA of course. I've not
tried the Rocket I/Os yet, although they are wired up on a couple of boards.
> Are you getting and passing EMI compliance testing?

Yes. Most of the problems come from inter board connections. I'm trying to
move to using the Rocket I/Os for this.
The microvias are a big help for getting termination resistors right where
you want them. I use packs of 2 (1mm square) and 4 (2mm x 1mm) resistors for
this, with vias in the pads.

> Have you tried or considered using thin layers between power (also signal
in
> your case)
> and ground planes instead of or in addition to bypass caps?

No. I reasoned that the tiny amount of (admittedly v. high Q) capactitance
you gained by doing this is pissed away by the inductance of the vias,
tracking, balls, and tracking on the FBGA substrates.

> Do you do SI/EMI simulations or just build these boards? :)

HyperLynx is my friend! Or it would be if I could get IBIS models of the
LVDS_DT inputs!
When I mentioned earlier that I've had EMI problems with interboard
connections, I had a processor address and data bus from another board that
connected to a V2PRO. By the time the 3.3V signals got to my FPGA, I had
overshoot to 5.5V and undershoot to -2V before the diodes clamped the
signals. The uP board designer had used sub-ns buffer-drivers from IDT to
drive the 50MHz bus over a 2mm pitch connector. (Those IDT buffers, they're
really quick!) So, demonstrating to the guy who spends the R&D cash, I
lifted the power pins to the IDT parts and put 50 Ohm resitors in series.
The overshoot vanished, leaving the undershoot unchanged. When I put
resistors in series with the ground pins of the IDT buffers, the undershoot
went as well. When I used HyperLynx to model the system, I got the same
results. Purchase Request for HyperLynx was signed!

>
> Thanks for sharing this!  Awesome stuff!
>
> Thanks,
> Ken
>
>



Article: 75126
Subject: Re: PCBs for modern FPGAs.
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 26 Oct 2004 11:36:07 -0700
Links: << >>  << T >>  << A >>
Hi Sylvain,
Comments below!
Best, Syms.
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message
news:417e148b$0$7082$ba620e4c@news.skynet.be...
> What's the diameter/restring of micro vias ?

Hole is 6mils, land is 14. 150um and 350um in new money. ;-)

> I don't see them in the 'capabilities' of the pcb supplier I'd like to
use.
> They however have blind vias with hole diameter down to 50µm. I guess that
> would work.
>
>
> What is warpage btw ?
>
It's a made up word that means how much the board warps or bends after, or
even during, reflow and the like. Too much prevents the devices soldering
properly, which is why the datasheets always have a coplanarity spec. for
the pins. I guess BGAs are probably less affected by this than QFPs
>
>
> Sylvain



Article: 75127
Subject: Re: JTAG Registers
From: "kopriva" <ivan.koprivnic@mail.inet.hr>
Date: Tue, 26 Oct 2004 20:41:27 +0200
Links: << >>  << T >>  << A >>
it is.



Article: 75128
Subject: Re: PCBs for modern FPGAs.
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 26 Oct 2004 11:44:49 -0700
Links: << >>  << T >>  << A >>
Hi Tim,
These guys helped me develop this stuff. Highly recommended, intelligent and
open to trying out new stuff! And they also used to beat us every year in
the annual inter-company cricket match!
http://www.graphic.plc.uk/

I've since moved jobs/continents, so I now use
http://www.ddiglobal.com
HTH, Syms.

"Tim" <tim@rockylogic.com.nooospam.com> wrote in message
news:cllk8q$jnl$1$8300dec7@news.demon.co.uk...
>
> Where do you get your prototype boards fabbed?
>




Article: 75129
Subject: Re: Introducing MANIK - a 32 bit Soft-Core RISC Processor
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 26 Oct 2004 11:46:55 -0700
Links: << >>  << T >>  << A >>
"David Brown" <david@no.westcontrol.spam.com> writes:
> The  x86 architecture is propritery,
> or "closed" - you need a license to be able to make an implementation.

Since when?

Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs
were licensed by Intel?

Article: 75130
Subject: Re: JTAG Configuration
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 26 Oct 2004 11:48:33 -0700
Links: << >>  << T >>  << A >>
Ivan,

 From the designers:

"VCCO_0 can be powered with 2.5V or 3.3V and the JTAG interface
will work at that voltage. there is no need for any pull ups
or supporting resistors on these pins.

the user's guide will be fixed because it is plainly misleading."

Thanks for finding this for us!

Austin

Ivan wrote:
> Hi,
> 
> Did anyone know what is the Xilinx recommended pull-up register value
> for the JTAG configuration pins (TCK, TMS, TDI, TDO and M0-M2) for
> Virtex4?
> 
> Thanks,
> Ivan

Article: 75131
Subject: Re: PCBs for modern FPGAs.
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 26 Oct 2004 12:10:40 -0700
Links: << >>  << T >>  << A >>
Rick,
Comment below.
Cheers, Syms.
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:417E75DB.8503C550@yahoo.com...
>
> The current board uses one ground, one power, split with some extra
> power traces running on a signal layer.  I had been planning to keep
> that the same.  Sounds like you are suggesting two ground layers and
> another for power, no?
>
Yes, once I saw all these different core and I/O supplies appearing, I
decided to concentrate on the ground layers and track/local-plane the
powers. It also makes analysing the SI stuff a lot easier, because there's
always a nearby ground plane for every signal's return current to travel
along. Check out http://www.sigcon.com/Pubs/news/6_04.htm for an example.
Sounds like your board is already very busy wrt signal layers. Must be
pretty dense.

> Do you have a ball park number for the additional cost of microvias?  I
> guess I would need to plug that into some quote web pages to see.
>
Yeah, the cost depends on so many things. You've gotta work with your PCB
house to work out what's best. I guess what I'm trying to say is that by
spending on the laser vias, you save on the layers.
Another point is that cheap overseas PCB fabs often can't produce these
boards. They're geared up for mass produced boards. But your local PCB
company can. So sometimes, for the right application, you end up with a
cheaper board, produced locally with all those support, turn-around time,
quality benefits that brings while keeping the bean-counters happy too...
Cheers, Syms.





Article: 75132
Subject: Re: Clock Extraction from Bi-Phase Data
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 26 Oct 2004 12:21:37 -0700
Links: << >>  << T >>  << A >>
Dave,
Check out XAPP224 from Xilinx.
http://www.xilinx.com/bvdocs/appnotes/xapp224.pdf
Might give you some ideas!
Cheers, Syms.
"Dave Garnett" <dave.garnett@metapurple.co.uk> wrote in message
news:417e3339$1_1@127.0.0.1...
>
> So, out of curiosity, how would you do it if the BiPhase clock was around
> 80MHz ? (ideally Spartan 2 based)
>
> Dave
>



Article: 75133
Subject: Re: Clock Extraction from Bi-Phase Data
From: Thomas Rudloff <thomasREMOVE_rudloffREMOVE@gmx.net>
Date: Tue, 26 Oct 2004 22:04:47 +0200
Links: << >>  << T >>  << A >>
KVP wrote:

>How can we extract clock from bi-phase encoded data (3.072Mbps -
>AES/EBU Data) using CLKDLL of Xilinx FPGA. The clock should be able to
>adjust itself to any slight drifting of the bi-phase data.
>  
>
Hi KVP,

I am working on something similar. You cannot use the 48MSPs to recover 
your clock in the DLL because the sync patterns have a bi-phase 
violation. The lowest clock you can recover is 64 / 4 * 48kHz = 768kHz. 
This is too slow for that fast DLL. One solution I thought about was 
switching the DLL input to its output while sync. But what is on 
transmission errors? Your DLL will go out of control. My intention is 
using a 32.768MHz VCXO and a FIFO. The VCXO is FLLed to the recovered 
input. So you use the AES syncs to FLL to your clock.

See also the thread "VCXO emulation" in this NG.

Regards
Thomas

Article: 75134
Subject: Re: Small survey for Handel-C writer
From: pierrotlafouine@hotmail.com (Pierre Lafrance)
Date: 26 Oct 2004 13:09:34 -0700
Links: << >>  << T >>  << A >>
pierrotlafouine@hotmail.com (Pierre Lafrance) wrote in message news:<d77de4d1.0410210743.5db6ce79@posting.google.com>...
> How long it took you to get used to Handel-C language, feel confident in
> the code you write ?
> 
> Thanks

up

Article: 75135
Subject: Re: Webpack 6.3i support for Spartan 3
From: Steve Lass <lass@xilinx.com>
Date: Tue, 26 Oct 2004 14:25:37 -0600
Links: << >>  << T >>  << A >>
Not really.  It was a conscious decision to avoid having to provide 2 
different service packs.

Steve

Gavin Scott wrote:

>Steve Lass <lass@xilinx.com> wrote:
>  
>
>>6.3i service pack 2 included the larger Spartan3 devices, so even 
>>WebPACK customers will have access
>>to those devices.  The 7.1i WebPACK will not include the 3S2000 and 3S4000.
>>    
>>
>
>Ah so it *was* a screw-up and those devices were never intended to be
>included then? :-)
>
>G.
>  
>


Article: 75136
Subject: Re: inefficient mux synthesis in quartus
From: filtered@psychosanity.com (Extrarius)
Date: 26 Oct 2004 13:48:13 -0700
Links: << >>  << T >>  << A >>
eliben@gmail.com wrote in message news:<1098778698.183224.270780@z14g2000cwz.googlegroups.com>...
> [...]A colleague suggested to replace the "for" with an explicit
> if..elsif of 25 clauses. I said "no way" - it's the same, and
> Quartus should be smart enough to figure it out. Surprise !
> Quartus isn't. [...]

Another reason the for loop isn't equal to if..elseif: The for loop
checks the variable against the loop value for every iteration of the
loop reguardless fo past equality, like a series of ifs without any
elseifs. You need to break out of the loop inside the if statement to
make it similar to if..elseif.

At least, I think I read something like that on here before. I don't
know enough about it yet to be sure that I'm remebering correctly.

-Extrarius

Article: 75137
Subject: Re: Low-power FPGAs?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 27 Oct 2004 10:39:48 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Jim,
> 
> Vccaux is required, as is Vcco for the config bank.

Power of VccAux ?
Are you saying Non-config banks can be Vcco removed, if desired ?
[eg a DRAM interface could de-power the DRAMS, and their Banks ?]

> 
> There is the Power On Reset control circuit wired to these three supply 
> sources.  If the POR trips going low, then memory is zeroized when POR 
> comes back up (On).
> 
> The static Icco is pretty low, I think less than 2 mA per bank (at 3.3V, 
> less at a lower Vcco).  Still gathering data on that for the data sheet.
> 
> The proposal I heard (from one engineer) was to run all LVDS IO, with a 
> few 2.5 V 2 mA CMOS single ended IOs for things like LEDs, switches, 
> slow peripherals (like the power controller).
> 
> Turns out that LVDS IOs are constant 4mA each (hi or lo), so single 
> ended IOs would be much more efficient (but slower).
> 
> The idea was to also go to the abs min voltages allowed for the sleep 
> mode (e.g 1.0V), and the recommended mins for operation.
> 
> If that did not do it, they wanted to know if we would consider a test 
> program to verify even lower sleep and operating voltages.
> 
> Good news is that the V4 is the most CMOS'sy chip we have had in awhile 
> -- it really works well at lower voltages int eh interconnect, CLB and 
> other simple functions.  The complex functions (MGT, DCM, PPC) are not 
> likely to be as forgiving if run out of spec.
> 
> As I said before, test programs are just money, so if it is worthwhile, 
> then it is considered.  We just need to be sure that we can yield 
> reliably to the screen, and it makes business sense to do it.  It would 
> not do anyone any good if the screen suddenly stopped yielding any parts 
> due to a small process shift.  Such screens are never entered into 
> lightly, and require a great deal of work (hence the reason why there is 
> usually a large volume involved).
> 
> Often as we gain more data from a new part, we may change specifications 
> (expand the operating ranges, speed up paths, etc.) so we will have to 
> wait.

  This is sounding a good direction, similar to Mobile Pentiums/Athlons.
There are SMPS devices with quite wide binary control of Vout, designed 
for the CPU markets.

Also, devices like the new LTC6905
http://www.linear.com/pc/productDetail.do?navId=H0,C1,C1010,C1096,P7888
also has power-save promise, by clock-vary 17:170MHz at reasonably low 
power levels.

  Most small micropower uC have clock-out options, that can also be used
if some portion of the FPGA needs to 'tick-over' - I think from what you
are saying, that the complex blocks, DLLs etc do not work as low as
the logic fabric, and config SRAMs - so something like an LCD interface,
or a keypad scan could run at < 1MHz at the lower Vccs ?
  [ that would allow users to choose between a really small uC, and
some sytem IO in the FPGA, or a larger uC with more pins, and more
agressive power-removals on the FPGA. ]


-jg



Article: 75138
Subject: Re: Low-power FPGAs?
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 26 Oct 2004 15:48:04 -0700
Links: << >>  << T >>  << A >>
Jim,

Yes, if all you want to do is 'sleep', you can remove power from the 
Vcco banks other than the one with the POR circuit on it.

The intrinsic protection diodes are always there, so if other circuits 
are powered, you may end up powering the Vcco of the banks through the 
diodes.

Austin



Jim Granville wrote:
> Austin Lesea wrote:
> 
>> Jim,
>>
>> Vccaux is required, as is Vcco for the config bank.
> 
> 
> Power of VccAux ?
> Are you saying Non-config banks can be Vcco removed, if desired ?
> [eg a DRAM interface could de-power the DRAMS, and their Banks ?]
> 
>>
>> There is the Power On Reset control circuit wired to these three 
>> supply sources.  If the POR trips going low, then memory is zeroized 
>> when POR comes back up (On).
>>
>> The static Icco is pretty low, I think less than 2 mA per bank (at 
>> 3.3V, less at a lower Vcco).  Still gathering data on that for the 
>> data sheet.
>>
>> The proposal I heard (from one engineer) was to run all LVDS IO, with 
>> a few 2.5 V 2 mA CMOS single ended IOs for things like LEDs, switches, 
>> slow peripherals (like the power controller).
>>
>> Turns out that LVDS IOs are constant 4mA each (hi or lo), so single 
>> ended IOs would be much more efficient (but slower).
>>
>> The idea was to also go to the abs min voltages allowed for the sleep 
>> mode (e.g 1.0V), and the recommended mins for operation.
>>
>> If that did not do it, they wanted to know if we would consider a test 
>> program to verify even lower sleep and operating voltages.
>>
>> Good news is that the V4 is the most CMOS'sy chip we have had in 
>> awhile -- it really works well at lower voltages int eh interconnect, 
>> CLB and other simple functions.  The complex functions (MGT, DCM, PPC) 
>> are not likely to be as forgiving if run out of spec.
>>
>> As I said before, test programs are just money, so if it is 
>> worthwhile, then it is considered.  We just need to be sure that we 
>> can yield reliably to the screen, and it makes business sense to do 
>> it.  It would not do anyone any good if the screen suddenly stopped 
>> yielding any parts due to a small process shift.  Such screens are 
>> never entered into lightly, and require a great deal of work (hence 
>> the reason why there is usually a large volume involved).
>>
>> Often as we gain more data from a new part, we may change 
>> specifications (expand the operating ranges, speed up paths, etc.) so 
>> we will have to wait.
> 
> 
>  This is sounding a good direction, similar to Mobile Pentiums/Athlons.
> There are SMPS devices with quite wide binary control of Vout, designed 
> for the CPU markets.
> 
> Also, devices like the new LTC6905
> http://www.linear.com/pc/productDetail.do?navId=H0,C1,C1010,C1096,P7888
> also has power-save promise, by clock-vary 17:170MHz at reasonably low 
> power levels.
> 
>  Most small micropower uC have clock-out options, that can also be used
> if some portion of the FPGA needs to 'tick-over' - I think from what you
> are saying, that the complex blocks, DLLs etc do not work as low as
> the logic fabric, and config SRAMs - so something like an LCD interface,
> or a keypad scan could run at < 1MHz at the lower Vccs ?
>  [ that would allow users to choose between a really small uC, and
> some sytem IO in the FPGA, or a larger uC with more pins, and more
> agressive power-removals on the FPGA. ]
> 
> 
> -jg
> 
> 

Article: 75139
Subject: Re: inefficient mux synthesis in quartus
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Tue, 26 Oct 2004 23:15:56 GMT
Links: << >>  << T >>  << A >>
Hi eli,


> I'll give it a try. Thanks !
> 
> Eli

Just a few statistics:

Using Quartus II 4.1 SP2, the following code

==== Cut here ====
library ieee;
use ieee.std_logic_1164.all;

entity zort is
  port (
    clk    : in  std_logic;
    inbus  : in  std_logic_vector(199 downto 0);
    sel    : in  integer range 0 to 24;
    outreg : out std_logic_vector(7 downto 0)
  );
end zort;

architecture rtl of zort is
begin
  process(clk)
  begin
    if rising_edge(clk) then
      outreg <= inbus(7 downto 0);
      for i in 0 to 24 loop
        if sel = i then
          outreg <= inbus((i*8)+7 downto (i*8));
        end if;
      end loop;
    end if;
  end process;
end architecture;
==== Cut here ====

produces 150 LEs when MUX optimization is forced ON, 163 LEs when it's set
to AUTO (lots of room left in the device, so Quartus doesn't bother), but
191 with the default assignment left out. No wonder you're getting worse
timing.

Best regards,


Ben



Article: 75140
Subject: Re: OPB in Verilog
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 27 Oct 2004 09:16:05 +1000
Links: << >>  << T >>  << A >>
Hi Andres,

Andres Calderon wrote:
> Somebody can send an example, document or advice to help me in the
> verilog implementation of a OPB module (EDK 6.2)

The opb_hwicap core in EDK6.2 is written in Verilog.

/path/to/edk/hw/XilinxProcessorLib/pcores/opb_hwicap/...

Regards,

John

Article: 75141
Subject: Re: JTAG Registers
From: "Antti Lukats" <antti@case2000.com>
Date: Tue, 26 Oct 2004 19:32:09 -0700
Links: << >>  << T >>  << A >>

"Prashanth" <prashanth.thota@gmail.com> wrote in message
news:be62eac0.0410260832.7f92146b@posting.google.com...
> Hi Folks,
>
> Is it possible to send user commands through JTAG to the internal
> Logic in the FPGA ? More Specifically a Spartan 3 FPGA.
>
> Thanks,
> Prashanth

defenetly! using the BSCAN primitive that "routes" to instructions USER1 and
USER2 to the FPGA fabric.



Article: 75142
Subject: Re: Best Place and Route
From: Marc Randolph <mrand@my-deja.com>
Date: Tue, 26 Oct 2004 21:54:49 -0500
Links: << >>  << T >>  << A >>
Wong wrote:
> Hi,
>   Recently I am doing P&R for my FPGA Design. Unfortunately, whenever
> I using the auto P&R provided in the software, I wont find a
> satisfactory result since some internal flip-flops alway have timing
> violations due to the routing, i.e. D-flipflop with setup time
> violation with respect to CLK, etc.
>   So I doubt that whether a manual P&R is possible under this
> circumstance. If yes, what are the golden rules to do this manual P&R
> without any tool like floorplanning ? I will assign the gate/cells one
> by one into the FPGA.

Howdy Wong,

    Your description is not detailed enough for anyone to give you a 
good answer.  A copy of *part* of the detailed timing report would go a 
long ways towards showing what is wrong (hopefully it shows clock rate 
as well as routing and component delays).

Your problem could be caused by any number of issues, from too many 
levels of logic to plain old poor placement (either due to the device 
being full, too empty, or just bad decisions by the placer), and all the 
stuff that goes between.  Or maybe it's close and just needs a different 
seed.

Good luck,

    Marc

Article: 75143
Subject: Re: Altium board again
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 27 Oct 2004 01:32:36 -0400
Links: << >>  << T >>  << A >>
Repzak wrote:
> 
> >> http://www.altium.nl/corp/media/pdfs/20041025_altium_mr_jtag_cable.pdf
> 
> it is a litle funny it is rated to 49$ in this file, know it is rated to 99$
> and in the EU to 99?

I thought that as well.  But if you read the text carefully, you will
see they are talking about a different kit.  The $49 kit is for use with
your custom board.  They just give you the cable and a 30 license on the
software, no board included.  

-- 

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: 75144
Subject: Re: inefficient mux synthesis in quartus
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 27 Oct 2004 02:50:03 -0400
Links: << >>  << T >>  << A >>
eliben@gmail.com wrote:
> 
> I'm not sure about synthesis, but Modelsim doesn't eat it - it
> wants a constant expression in the array indices. I tried it
> before I created the "for" hack, it didn't compile.

You might try writing to Ben Cohen about this since it is in his book. 
The title is "HDL Chip Design", the example is in section 7.9
Multiplexer Model, p 202-203.  Here is the code example...

library IEEE;
  use IEEE.Std_Logic_1164.all;
  use IEEE.Std_Logic_Arith.all;

entity Mux is
  port (DataIn    : in   Std_Logic_Vector(17 downto 0);
        MuxSelect : in   Std_Logic_Vector( 4 downto 0);
        MuxOut    : out  Std_Logic);
end Mux;

architecture Mux_a of Mux is 
begin
  -- Multiplexer 18 to 1
  MuxOut <= DataIn(Conv_Integer(Unsigned(MuxSelect)))  when
               MuxSelect < "10010"                     else
            'X';
end Mux_a;

I am also suspect of the '<' comparison between the two SLVs.  I am not
aware that there is an operator defined for this.  But maybe the library
IEEE.Std_Logic_Arith defines this.  The absence of this test may be what
caused the error in your case since you could have indexed outside the
array index range.  Personally, I would define MuxSelect to be a integer
constrained to the range valid for this case.  

You might even contact Ben Cohen directly.  He seems to be a pretty good
guy and I expect he would be happy to answer any questions about
possible mistakes in his book.  vhdlcohen AT aol D0T com

Let us know what you find.  

-- 

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: 75145
Subject: SPARC V8 SoC in FPGA? Its already cost effective!
From: "Antti Lukats" <antti@case2000.com>
Date: Wed, 27 Oct 2004 08:51:55 +0200
Links: << >>  << T >>  << A >>
SPARC Based FPGA SoC system

I have always being amazed about the "art" of VHDL programming done by
Gaisler Research, but the new release of GRLIB for LEON3 is even better.

GRLIB includes
- LEON3 (Sparc V8) Processor, cache, hardware mul/div, AMBA bus interface
- ROM/RAM Controller
- PC133 SDRAM Controller
- Floating Point unit
- AMBA Cores:
- Plug and Play AHB controller (peripheral module identify!)
- AHB/PHB Bridge (plug and play)
- AHB/APB reporting modules
- AHB PCI (master/target)
- PCI DMA Controller
- AHB adapter for opencores ehternet IP
- APB UART
- APB Timer
- APB GPIO
- Interrupt Controller

additionally are included several simulation cores and models.

GLIB is configured using flexible scripting system that supports
"hw board support packages" that is the makefile can select what
target hw board is used and configures all the toolchain for it.

makefiles can be used to start different simulators or generate
bitstream using either xilinx or synplify synthesis.

There is no GUI builder (aka XPS in EDK) but when the bus modules
are simply "wired" together in the toplevel module then all the
bus arbitration is done automatically. So creating a customized
SoC doesnt take more than few hours.

Of course available is full GNU compiler toolchain and scripts
to compile example programs.

LEON3 can be used for uCLinux and Linux (demo images for both
are available).

Debug unit allows full access to the AHB bus so it can read
write to memory and peripherals. Special DSUMON application
can be used to communicate with the debug module. DSUMON
is also able to serve as GDB server so GDB debugger can be
used as well.

Cycle accurate Instruction set simulator is available as well.

LEON3 SoC seems to use a bit more FPGA resources then as example
MicroBlaze based system, I did an example SoC (with about the
amount of peripherals)

MicroBlaze Soc: 1700 Slices
Sparc SoC: 3500 Slices

What I would like to know is how much would the Sparc SoC
decrease in resources if resynthesised using Synplicity Amplify,
my bet is that it would come down to approx 2400 Slices from 3500

But even so, with XST synthesis its obvious that Sparc based SoC
is already heavy competion to vendor SoC systems, specially when
targetting the latest FPGA families and larger chips.
In XC2V1000 the Small Sparc SoC takes around 50% (XST synthesis)
what is relativly heavy price, but in larger family member and in
case the peripheral IPs are large the actual percentage consumed
by Sparc CPU comes smaller.

Of course I could imagine that its not so complicated to develop
a Sparc-Lite version that could compete with resource useage
with vendor CPU solutions.

Why I wrote this? Because I think that LEON3/GRLIB has had too
few exposure, and well I always liked SPARC - it my personal
favorite ISA. Once upon a time I wanted to obtain Sparc CPU
chips made by Plessey, I had some idea for an commercial
product - I never got them, by my idea still lives one, and
now I can have the Sparc in low cost FPGA, thats great!

Antti Lukats

















Article: 75146
Subject: Re: Webpack 6.3i support for Spartan 3
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 27 Oct 2004 02:59:27 -0400
Links: << >>  << T >>  << A >>
Steve Lass wrote:
> 
> Not really.  It was a conscious decision to avoid having to provide 2
> different service packs.
> 
> Steve
> 
> Gavin Scott wrote:
> 
> >Steve Lass <lass@xilinx.com> wrote:
> >
> >
> >>6.3i service pack 2 included the larger Spartan3 devices, so even
> >>WebPACK customers will have access
> >>to those devices.  The 7.1i WebPACK will not include the 3S2000 and 3S4000.
> >>
> >>
> >
> >Ah so it *was* a screw-up and those devices were never intended to be
> >included then? :-)

Ok, I am still confused about this.  Does the current 6.3 webpack,
service pack 2 include the 3S2000/4000 or not?  Is it in now and will be
taken out in 7.1?  Oh, I think I understand now.  The two different
service packs are for the webpack and the ISE, right?  So the current
webpack *does* include all the spartan 3 devices, but will not in the
future.  Ok, I understand.  

-- 

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: 75147
Subject: Re: Low-power FPGAs?
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 27 Oct 2004 20:20:49 +1300
Links: << >>  << T >>  << A >>
I probably am misleading some what... but experience for a typical design is
FPGA's don't consume much.  they are usually the lowest power consumer on my
designs.  but done right....  An FPGA will draw less power than a micro
doing the same thing.  the last card had a dynamic current in the FPGA of
about 8 mA (excluding I/O) that's according the power calculator and the
interface it connected to could draw 2amps.  I don't think that's too bad.

And I usually do design to the spec... we rate our radios from  -10C to +65C
and aren't allowed more than 2 'noise' hits over a temperature cycle.  But
for a piece of test gear sitting on a bench.. I think you can go slightly
wild and limit the temperature range... unless you going to sit it in a shed
in a desert... which I doubt.

I saw your battery... not bad... but usually higher voltages win out over
higher amp-hour... at low voltages the switcher losses become silicon volt
drop related.  If you look at Maxium you will see they quite often invert
the voltage and then switch up from the sum of the voltages to get the
efficiency up when working with low voltages.

Am glad you like the Q FPGA.  I came across it while helping design a
satellite here.  Its fuse link, no free tools, no free programmer... so I
would defiantly prototype with something else until you can be assured of it
working.

For driving a FPGA from a CPLD.. you might need an interface IC in between.
There are a number of logic families that support hot-swap which should stop
any current draw when the chip is in power down.. failing that.. 10k
resisters are pretty good too :-)
Or you could make sure all devices drive the FPGA with a low by default...
then there is no power for the protection diodes to suck :-)

Simon


"Symon" <symon_brewer@hotmail.com> wrote in message
news:2u7hb2F25pfq8U1@uni-berlin.de...
> Hi Simon,
> A few comments included below, but do we agree that saying "FPGA's by
their
> very nature are low power.. provided you don't clock them fast." is
somewhat
> misleading?
> Cheers, Syms.
>
> "Simon Peacock" <nowhere@to.be.found> wrote in message
> news:417e23a9@news.actrix.gen.nz...
> > Forget a V2PRO... unless you need a power PC... there are far cheaper
> > options to get a processor.
> >
> > I also never suggested using bleeding edge... if you pick an 'older
part'
> > you will find the static current better... it just won't have the same
> > capability as the modern 90 nm parts.. although cyclone (cough cough)
seem
> > to have a lower quiescent current 12mA - 80 mA.. but they probably
cheated
> > to get that.
>
> The V2PRO I mentioned doesn't have a PowerPC, but anyway I'd question
> whether V2PRO is bleeding edge. (Bleeding irritating, maybe!) Anyway, even
> small plain old Virtex (50mA) and SpartanIIe (200mA) suffer from this
> Iccintq problem. I'll check out the A parts, thanks for the pointer.
>
> >
> > And even tho A or X seems good what about Q ?
> > Quicklogic Eclipse is a low power (not so) FPGA .. so they might be via
> > OTP... so you prototype with RAM based... but you can't beat the 22 -
250
> uA
> > quiescent current... and only 100mA at 100Mhz.
>
> Sounds like a good solution.
>
> >
> > Don't forget the option of powering down when not in use, use a
coolrunner
> > to turn the FPGA off if necessary / possible just don't forget to shut
> down
> > I/O too.. or the saving will be killed by protection diodes.
> > Older FPGA's have smaller configurations and can be programmed fast if
you
> > externally clock them.
> >
>
> So, if the CPLD/FPGA you're powering down has live inputs from other
places,
> won't these inputs back power the part through the protection diodes? So,
> the inputs have to be off too?
>
> > And yea.. design to typical.. select of test even :-) unless your
running
>
> You bad boy! I'd never do that. (= I'd never admit to doing that!) ;-)
>
> >
> > at -20 or +60C .. but at 0C you NiMH battery life will be half that at
20C
> > too..
> > Then pick a better battery... heard of lithium ion? :-)
>
> What do you mean by better? Price? Also, Lion and NiMH have the same(ish)
> volumetric energy density. Are Lions better over temperature? Is self
> discharge better in Lions? (Sounds like a sticky mess in the Serengeti!)
>
> > You might also want to watch the D cells.. often the are a 'C' cell in
> side
> > a cardboard wrapper.  There are also special 'radio modeller' NiCAD's
that
> > have rather nice mAH ratings... designed for electric cars and planes.
> >
>
> I thought these special NiCds were high power cells, not high energy?
>
> > I have a battery pack here good for 600mA hours @ 8.4V... not much
bigger
> > than a D cell.
>
> Which is why it has the same(ish) energy storage as a NiMH D cell! 6.5Ah @
> 1.2V.
> http://www.panasonic.com/industrial/battery/oem/
> >



Article: 75148
Subject: Re: Introducing MANIK - a 32 bit Soft-Core RISC Processor
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Wed, 27 Oct 2004 09:43:05 +0200
Links: << >>  << T >>  << A >>

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qh3c01co68.fsf@ruckus.brouhaha.com...
> "David Brown" <david@no.westcontrol.spam.com> writes:
> > The  x86 architecture is propritery,
> > or "closed" - you need a license to be able to make an implementation.
>
> Since when?
>
> Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs
> were licensed by Intel?

I don't know the details, nor how much needs licenses, but I believe AMD and
Intel have cross-licensing deals on their x86 architectures.  I also
remember hearing about Intel suing companies for making one type of x86 chip
when they only had a license for a different generation of x86 designs.  At
least some of the licenses Intel has provided have not been by choice, but
by court order.

However, it could be that all this refers to something other than the x86
architecture itself (maybe something to do with the implementation, or
arrangements of special registers, or whatever), and the x86 is not
proprietry.  In that case, pick a different example, like ARM.




Article: 75149
Subject: JTAG Configuration
From: ivanlealx@yahoo.com (Ivan)
Date: 27 Oct 2004 01:25:09 -0700
Links: << >>  << T >>  << A >>
Hi,

Anyone know what is Xilinx recommended pull-up resistor value for
Virtex-4 configuration pins (TCK, TDO, TDI, TMS and M0-M2)?

Thanks,
Ivan



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