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 116100

Article: 116100
Subject: Re: $recovery
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Thu, 1 Mar 2007 17:55:50 +0100
Links: << >>  << T >>  << A >>
i'd say Yes...But make sure it's only teh asynchronous reset thats causing 
these problems, nothing else.  And even then I recommend you have a look 
around for debates over synch vs asynch reset... it's one of these issues 
that is unpredictable, and can make your circuits really misbehave...
Ben




"skyworld" <chenyong20000@gmail.com> wrote in message 
news:1172720587.730126.106160@s48g2000cws.googlegroups.com...
So do you mean that I can ignore these warnings?




On 2ÔÂ27ÈÕ, ÏÂÎç4ʱ57·Ö, "Benjamin Todd"
<benjamin.toddREMOVEALLCAPIT...@cernREMOVEALLCAPITALS.ch> wrote:
> normally you wont have specified any time constraints on the reset 
> signal...
> I aam assuming you have a global asynchronous reset.
>
> To correctly manage the reset you should try to synchronise it to the
> internal clock using a couple of flip-flops.  This way it ensures a
> synchronous release of the reset that can be treated and analysed in the
> same way as any other.  I think you may still get the warnings for
> violations of the first asynchronous input.
>
> Anyways, the idea of synchronous vs asynchronous reset is a long 
> discussion
> =)
>
> Ben
>
> "skyworld" <chenyong20...@gmail.com> wrote in message
>
> news:1172557239.722343.245410@p10g2000cwp.googlegroups.com...
>
> > Hi,
> > I am doing FPGA design with xilinx spartan 3e. When I finished P&R, I
> > checked the timing report. Everything is ok, and there is no timing
> > violations. But when I run post simulation, the modelsim reports some
> > timing errors for some registers with $recovery(...). I checked the
> > time when these errors occur. They happened to be the time when reset
> > is de-assertion. I tried to change reset period, but this time other
> > register report $recovery/$setup/$hold errors. It is very strange
> > because I have passed P&R, there is no timing violations, why does
> > these errors orrur? Can anybody help me? thanks very much.




Article: 116101
Subject: Re: what does a 'blank check' do exactly
From: Tim <tim@nooospam.roockyloogic.com>
Date: Thu, 01 Mar 2007 16:57:27 +0000
Links: << >>  << T >>  << A >>
mtsukanov@gmail.com wrote:

> Yea I actually tried doing 'id code' read, it didn't do anything,
> didn't produce the same results as doing a 'blank check' or
> reprogramming.

check that you have the correct pullups/pulldowns on the JTAG pins.


Article: 116102
Subject: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "wallge" <wallge@gmail.com>
Date: 1 Mar 2007 09:10:48 -0800
Links: << >>  << T >>  << A >>
Does anyone know if there is a dev kit available for an MPEG encoder
ASIC - preferably one that
I could connect to a real-time video source as input and connect to an
FPGA board for post processing...
In otherwords an MPEG ASIC dev kit with a lot of IO options.

Also can anyone suggest a (separate, additional) dev kit that would
support reading and riding to a hard disk, preferably one that would
come with its own HDD controller onboard, that could be talked to via
an external microproc or FPGA.

thanks


Article: 116103
Subject: Re: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "larwe" <zwsdotcom@gmail.com>
Date: 1 Mar 2007 09:36:38 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 12:10 pm, "wallge" <wal...@gmail.com> wrote:
> Does anyone know if there is a dev kit available for an MPEG encoder
> ASIC - preferably one that
> I could connect to a real-time video source as input and connect to an
> FPGA board for post processing...

If you already have an FPGA, why use an MPEG ASIC? You can encode MPEG
in your FPGA.


> Also can anyone suggest a (separate, additional) dev kit that would
> support reading and riding to a hard disk, preferably one that would

Again, if you have an FPGA, why do you need an external "development
kit"? If you are willing to use standard parallel ATA (as opposed to
the let's-line-Intel's-pockets SATA drives) it is fairly trivial to
interface to a hard disk.


Article: 116104
Subject: Re: Virtex 4 FX Sonet Alignment
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 1 Mar 2007 09:39:55 -0800
Links: << >>  << T >>  << A >>
Wow.  From UG076
Page 125:
"It is recommended that the SONET user application enable
ENPCOMMAALIGN and ENMCOMMAALIGN together, and then turn them both off
when alignment is achieved."

Page 195:
"SONET: [...] Always keep ENPCOMMAALIGN active to prevent data
misalignment."

Well, it's hard to meet both rules. So which one should take
precedence?

Kolja



Article: 116105
Subject: Re: what does a 'blank check' do exactly
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 1 Mar 2007 09:45:22 -0800
Links: << >>  << T >>  << A >>
<mtsukanov@gmail.com> wrote in message 
news:1172763684.644449.311760@n33g2000cwc.googlegroups.com...
>
> Hmm... I'm not completely sure I understand what u said, but let me
> clarify a little more on what's happening:
>
> The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> CPLD is doing is connecting the signals going from the PROM to the
> FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> CPLD, it works right away, and the FPGA gets programmed from the PROM.
> If I turn off the POWER to the whole system, turn it back on - nothing
> happens. The FPGA does'nt get programmed from the PROM. *IF at that
> point I right click on the CPLD in Impact, and select 'blank check',
> the CPLD starts 'working' and the FPGA gets programmed. The V4 is
> working in 'master' mode, and I checked the CCLK and it runs just fine
> after board powerup, thought the d_in has garbage on it. The d_in
> turns good when i do the 'blank check' on the CPLD or when I reprogram
> the CPLD. That's why I'm wondering if the 'blank check' drives the
> CPLD's pins to 0 or 1 during the 'blank check' operation, something
> funky like that
>
> thanks again, any help is much appreciated


You have just described a system and symptom completely unrelated to the 
typical questions devined by the "what happens when I do this" question.

You have a CPLD that doesn't just connect two parts.  You have a CPLD that 
powers up between two parts that power up.

Chances are the prom and FPGA are not both happy.  The blank check for the 
CPLD might do something that functionally changes the I/O.  Typically a 
blank check isn't used to ponder whether an operating device is blank so a 
"destructive" check is reasonable where outputs can tristate or change state 
while the device is interrogated.

Use a logic analyzer or similar device to look at the power-up behavior of 
the PROM control signals as well as the FPGA program control pins.  You 
probably have a misbehavior in the initialization because the CPLD isn't on 
at the right time - or correct power-on polarity - for the attached devices.

Your cure may be as simple as added pull-up/pull-down resistors or a little 
intelligence to make sure both devices around the CPLD are in reset.

The problem isn't around the "blank check" as implied by your initial 
superficial question (no depth) but in the CPLD's behavior in your FPGA 
initialization. 



Article: 116106
Subject: Re: Regional Clock Network and Large Designs
From: "Brandon Jasionowski" <killerhertz@gmail.com>
Date: 1 Mar 2007 09:45:32 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 7:12 am, "John McCaskill" <junkm...@fastertechnology.com>
wrote:
> On Feb 28, 11:12 pm, "Brandon Jasionowski" <killerhe...@gmail.com>
> wrote:
>
>
>
> > Hello,
>
> > I'm getting usual results from my BUFR network in Timing Analyzer:
>
> > <SNIP>
> > --------------------------------------------------------------------------------
> > Hold Violations: TS_adc1_dclk_p = PERIOD TIMEGRP "TG_adc1_dclk_p" 4 ns
> > HIGH 50%;
> > --------------------------------------------------------------------------------
> > Hold Violation:         -0.974ns (requirement - (clock path skew +
> > uncertainty - data path))
> >   Source:               adc1_reg_inst/nshifts_gen[1].dff_ins/d_r_7
> > (FF)
> >   Destination:          adc1_reg_inst/nshifts_gen[2].dff_ins/d_r_7
> > (FF)
> >   Requirement:          0.000ns
> >   Data Path Delay:      1.275ns (Levels of Logic = 0)
> >   Positive Clock Path Skew: 2.249ns
> >   Source Clock:         adc1_dclk rising at 0.000ns
> >   Destination Clock:    adc1_dclk rising at 4.000ns
> >   Clock Uncertainty:    0.000ns
> >   Timing Improvement Wizard
> >   Data Path: adc1_reg_inst/nshifts_gen[1].dff_ins/d_r_7 to
> > adc1_reg_inst/nshifts_gen[2].dff_ins/d_r_7
> >     Delay type         Delay(ns)  Logical Resource(s)
> >     ----------------------------  -------------------
> >     Tcko                  0.268   adc1_reg_inst/nshifts_gen[1].dff_ins/
> > d_r_7
> >     net (fanout=1)        1.065   adc1_reg_inst/d_array<2><7>
> >     Tckdi       (-Th)     0.058   adc1_reg_inst/nshifts_gen[2].dff_ins/
> > d_r_7
> >     ----------------------------  ---------------------------
> >     Total                 1.275ns (0.210ns logic, 1.065ns route)
> >                                   (16.5% logic, 83.5% route)
> > </SNIP>
>
> > 2.25 ns positive clock path skew? Omg!? So, then I looked at the
> > partially PAR'ed output on this SX55 FPGA. Turns out the stupid tools
> > are expanding the BUFR network across multiple BUFR regions, including
> > horizontally (x direction). I have an 8k FIFO (necessary) to
> > transition from this BUFR clock to a slower BUFG clock. Looks like the
> > tools are placing the FIFO on the left side of the FPGA and the top-
> > right BUFR is using non BUFR resources (I assume) to route the clock
> > across.
>
> > Is this what's causing my enormous clock path skew? I will try to
> > apply some area_group slice/bram constraints to my FIFOs, but I find
> > this to be an extreme pain in the butt... I'm using a COTS board,
> > which is configured with 4 ADC data channels and 4 ADC clocks. The ADC
> > data is about 180 degrees out of phase w/ the clock (fine). Is there a
> > way to constrain nets/instances/etc. to a regional clock region?
> > That'd be really sweet...
>
> > Is there a better way to transition from the regional clock to a
> > global clock other than using a FIFO? This is giving me a headache b/c
> > my design takes forever to PAR and I can't meet timing :(
>
> > Thanks,
> > -B
>
> When we first started using the regional clock buffer in our designs,
> the tools did not automatically place the logic that used that clock
> into the three clock regions that the clock could reach.  In my case,
> it just failed to route.  Our solution was to put an area group
> constraint on the logic that used that clock, and that fixed the
> problem. This was with a 7.x version of EDK/ISE.
>
> That little inconvenience aside, the BUFIOs and BUFRs are very nice.
> The BUFR is what makes it possible for us to meet timing for 66 MHz
> PCI on a V4FX60. As the FPGAs get bigger, the BUFG delays get longer.
> On PCI, you should not use a DCM to tune out the clock delay because
> the clock speed is allowed to vary, but I don't know how many system
> do that.
>
> Regards,
>
> John McCaskillwww.fastertechnology.com

Right. So I'm trying constraints like:

<SNIP>
INST "fifoadc1_inst" AREA_GROUP = "AG_fifoadc1_inst";
AREA_GROUP "AG_fifoadc1_inst" COMPRESSION = 100;
AREA_GROUP "AG_fifoadc1_inst" RANGE = SLICE_X48Y128:SLICE_X95Y255;
AREA_GROUP "AG_fifoadc1_inst" RANGE = RAMB16_X4Y16:RAMB16_X7Y31;
</SNIP>

Is there an area group constraint that's all encompassing, i.e.
includes FIFO16, DSP48, SLICES, RAMB16, etc.?

Thanks,
-Brandon


Article: 116107
Subject: Re: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "wallge" <wallge@gmail.com>
Date: 1 Mar 2007 09:46:59 -0800
Links: << >>  << T >>  << A >>
Well
(A) the encoder IP for the FPGA is VERY
expensive, (B) I am not going to write an MPEG encoder from scratch.
thats why i'd rather have an ASIC
and just pay for the chip itself.
Also I am doing a lot of other processing
on the FPGA and would like to not have
to worry about saving FPGA logic/ external memory access
for the the MPEG encoder.


On Mar 1, 12:36 pm, "larwe" <zwsdot...@gmail.com> wrote:
> On Mar 1, 12:10 pm, "wallge" <wal...@gmail.com> wrote:
>
> > Does anyone know if there is a dev kit available for an MPEG encoder
> > ASIC - preferably one that
> > I could connect to a real-time video source as input and connect to an
> > FPGA board for post processing...
>
> If you already have an FPGA, why use an MPEG ASIC? You can encode MPEG
> in your FPGA.
>
> > Also can anyone suggest a (separate, additional) dev kit that would
> > support reading and riding to a hard disk, preferably one that would
>
> Again, if you have an FPGA, why do you need an external "development
> kit"? If you are willing to use standard parallel ATA (as opposed to
> the let's-line-Intel's-pockets SATA drives) it is fairly trivial to
> interface to a hard disk.



Article: 116108
Subject: Re: xilinx block ram synthesis
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 1 Mar 2007 09:51:57 -0800
Links: << >>  << T >>  << A >>
The way I interpret your code as written, if the clock event happens and the 
reset is one, the RAM is not to be read or written.  While this can be 
assembled manually into a memory through correct ENA usage, it probably 
doesn't fit the synthesis template.

Consider separating the memory read/write into a separate process that has 
no reset.  Resets - even this one which isn't "intended" to affect the 
memory - tend to diffuse any attempts to infer a good BlockRAM.


"S.T." <st@iss.tu-darmstadt.de> wrote in message 
news:es6uu7$7ul$1@lnx107.hrz.tu-darmstadt.de...
> Hi
>
> Since Version 7.x xilinx xst is able to infer block ram out of appropriate
> vhdl statements. Unfortunately it is not working in the example given
> below. Does anybody have an idea why the code below gives the following
> warning:
>
> WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the 
> RAM
> contents is read synchronously.
>
> Thanks
> ST
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
>
> entity BRAM_test is
>        port (CLOCK : in std_logic;
>                reset : in std_logic;
>                di : in std_logic_vector(15 downto 0);
>                do : out std_logic_vector(15 downto 0));
> end BRAM_test;
>
> architecture syn of BRAM_test is
>
> type ram_type is array (1023 downto 0) of std_logic_vector (15 downto 0);
> signal RAM : ram_type;
> attribute ram_style : string;
> attribute ram_style of RAM: signal is "block";
>
> type STATE_TYPE is (P1, P2, P3);
> signal STATE : STATE_TYPE;
>
> signal addr : std_logic_vector(9 downto 0);
>
> begin
>        main : process (CLOCK, RESET)
>        begin
>                if (RESET = '1') then
>                        STATE <= P1;
>                        addr <= (others => '0');
>                elsif (CLOCK'event and CLOCK = '1') then
>                        case STATE is
>                                when P1 =>
>                                        RAM(conv_integer(addr)) <= di;
>                                        STATE <= P2;
>                                when P2 =>
>                                        do <= RAM(conv_integer(addr));
>                                        STATE <= P3;
>                                when P3 =>
>                                        addr <= addr + '1';
>                                        STATE <= P1;
>                        end case;
>                end if;
>        end process main;
> end syn;
> 



Article: 116109
Subject: Re: looking for the source VHDL for Jpeg 2000
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Thu, 01 Mar 2007 19:00:08 +0100
Links: << >>  << T >>  << A >>
Frederic wrote:
> Hello,
> 
> I am just looking for the Jpeg 2000 source in VHDL, can anyone help
> me?

Free ? 
I think you're a little optimistic ;)

And the "paying" cores are $$$ (well, that depends of the speed / profile / ... you need but not cheap).

What application do you have in mind ?


	Sylvain

Article: 116110
Subject: Re: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "larwe" <zwsdotcom@gmail.com>
Date: 1 Mar 2007 10:01:59 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 12:46 pm, "wallge" <wal...@gmail.com> wrote:

> Also I am doing a lot of other processing
> on the FPGA and would like to not have
> to worry about saving FPGA logic/ external memory

In that case, the best "evaluation platform" is probably a PC with a
PCI MPEG encoder card and a hard disk :)

Video encoder and decoder ICs tend to be terribly difficult to get
without NDAs, precisely because of all the expensive IP in them (and
the horrific thought that someone might build a device that doesn't
comply with whatever DRM bullshit the MPAA's bought politicians are
trying to peddle at the moment).



Article: 116111
Subject: apologia
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 01 Mar 2007 10:02:36 -0800
Links: << >>  << T >>  << A >>
All,

I had posted:

"How else is one measured, except by their commitments?
V5 has met all dates.  In fact, has exceeded them."

I now discover that we missed a delivery date for a shipment of ES
XC5V330 parts to a customer.

So, in fact, V5 XC5V330 missed a customer commitment.

As the largest FPGA part in existence, we were unable to meet the demand
so soon after first lot fab-out.

I apologize.

I also wish to thank the person who brought this to my attention,

Austin

Article: 116112
Subject: Help with Partial Reconfiguration on Spartan3
From: lucaroccasalva@gmail.com
Date: 1 Mar 2007 10:08:39 -0800
Links: << >>  << T >>  << A >>
Dear all,

I am trying to perform a module based partial reconfiguration on a
Spartan3 XC3S400 (on a 3SxLC board by MEMEC). I am using ISE
8.2.01i_PR_07b (sp1 with Early Access Patch)
I already was able to perform a difference based partial
reconfiguration without any problem, but when trying to perform a
module based reconfiguration, when I download via JTAG the partial
bitstream it seems that the device reconfigure itself totally: in
fact, the static part which only switch on and off a led stops
running.

I created the bitstream from the ISE using these command lines:
1) the total bitstream using <bitgen -w top.ncd top.bit>
2) the partial ones using <bitgen -g ActiveReconfig:Yes -d -w
partial.ncd partial.bit>

In the implementing phase I use the following additional options:
for the TRANSLATE phase <-u -aul>
for the MAP phase <-u>

Moreover when implementing the partial module synthesis I deasserted
the option "Add input-output buffers"

Is there someone else I should try?

I tried also to create the bitstream using the pearl script
(PR_verifydesign and PR_assemble) from the PR patch but I obtained
some errors. For instance, when I try to merge the static module with
the reconfigurable one using the PR_verifydesign static.ncd
dynamic.ncd I obtain the following error
"ERROR:  Illegal attempt to merge two designs that are not both
partial".

I hope you can help me. In case you need more information please let
me know

Luca


Article: 116113
Subject: Re: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "wallge" <wallge@gmail.com>
Date: 1 Mar 2007 10:44:08 -0800
Links: << >>  << T >>  << A >>
I know that I could just send pre-encoded
video to my FPGA and skip the encoder ASIC
step, but the whole point of my project is to put together
an embedded system, which a desktop computer is not part of.
Or at least proof of concept for an embedded system...

On Mar 1, 1:01 pm, "larwe" <zwsdot...@gmail.com> wrote:
> On Mar 1, 12:46 pm, "wallge" <wal...@gmail.com> wrote:
>
> > Also I am doing a lot of other processing
> > on the FPGA and would like to not have
> > to worry about saving FPGA logic/ external memory
>
> In that case, the best "evaluation platform" is probably a PC with a
> PCI MPEG encoder card and a hard disk :)
>
> Video encoder and decoder ICs tend to be terribly difficult to get
> without NDAs, precisely because of all the expensive IP in them (and
> the horrific thought that someone might build a device that doesn't
> comply with whatever DRM bullshit the MPAA's bought politicians are
> trying to peddle at the moment).



Article: 116114
Subject: Re: Bypass caps, X2Y and 'puddles'.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 02 Mar 2007 08:07:35 +1300
Links: << >>  << T >>  << A >>

Symon wrote:
> Hey Guys,
> It's a been a while since we had a bypass capacitor religious war, so I 
> thought I'd stir things up a bit!
> Seriously, I've been reading about X2Y capacitors, and a search of the 
> newsgroup revealed that these very interesting parts have only been 
> mentioned once or twice in passing. (By Austin, natch!)
> 
> Check out :-
> http://www.teraspeed.com/publications.html
> Where they ask you to register for :-
> http://www.teraspeed.com/papers/cap_considerations_fpga_pds.pdf
> 
> Steve Weir does a great job of showing why X2Y caps give you more bang for 
> your buck. As these parts have exceptionally low inductance, they can 
> substantially reduce the number of capacitors AND vias you need, and they 
> quote that :-
> "Can replace from three to six+ regular caps depending on via and plane 
> geometries"
> "Vias at $0.005/hole / $0.01 / capacitor typical, often COST MORE than the 
> capacitors they connect!"
> 
> Here's another interesting article:-
> http://www.x2y.com/bypass/mount/backside_cap.pdf
> 
> They recommend using small 'puddles' of copper to connect all the bypass 
> elements together so you can use fewer capacitors but keep the same bypass 
> network performance.
> 
> Check out http://www.x2y.com/bypass.htm for more articles.
> 
> AFAICS, the main drawback is that X2Y caps are available in a range of 
> values. This means nutters will use several different values in their bypass 
> networks to create 'resonances' and the like. :-)
> 
> Anyway, I hope this is of interest, Syms.

Interesting.
They are correct, but also use a couple of small 'goal post shifting' 
techniques.

* The vias to 'their' caps, have a larger copper cross section, than to 
other caps.
* they choose to compare 100nf (others) against their 56nf.
   Claiming you double their cap, is not quite correct.
   What they should compare, is their 56nf, against 2 x 56nF others

I agree with this
"Mounted ESL for an X2Y® on a 4/6 layer PCB is completely dominated by 
the attachment inductance..."


-jg



Article: 116115
Subject: What is the running frequency for a typical FPGA application using Virtex 5
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 1 Mar 2007 11:16:46 -0800
Links: << >>  << T >>  << A >>
Hi,
What is the running frequency for a typical FPGA application using
Virtex 5?

A friend of mine told me long ago that we could expect to get 1/10
running frequency of the fastest CPU for a fastest FPGA in market.

Now the fastest CPU runs at 4GHz, can a FPGA application using the
fastest FPGA chip be expected to run at 400MHz, 1/10 of fastest CPU?
Is Virtex 5 the fastest FPGA so far?

For example, DDR2 runs at 333MHz, can a DDR2 application core run
normally at 333MHz without any trouble such that there is no need to
reduce application core running frequency to meet 333MHz challenge? If
so for Virtex 5, it can be claimed that 333MHz is achievable.

1/10 ratio between the fastest CPU and the fastest FPGA chip running
frequencies is a reasonable expectation or not?

Thank you.

Weng


Article: 116116
Subject: Re: what does a 'blank check' do exactly
From: mtsukanov@gmail.com
Date: 1 Mar 2007 11:16:57 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 12:45 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> <mtsuka...@gmail.com> wrote in message
>
> news:1172763684.644449.311760@n33g2000cwc.googlegroups.com...
>
>
>
>
>
> > Hmm... I'm not completely sure I understand what u said, but let me
> > clarify a little more on what's happening:
>
> > The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> > CPLD is doing is connecting the signals going from the PROM to the
> > FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> > CPLD, it works right away, and the FPGA gets programmed from the PROM.
> > If I turn off the POWER to the whole system, turn it back on - nothing
> > happens. The FPGA does'nt get programmed from the PROM. *IF at that
> > point I right click on the CPLD in Impact, and select 'blank check',
> > the CPLD starts 'working' and the FPGA gets programmed. The V4 is
> > working in 'master' mode, and I checked the CCLK and it runs just fine
> > after board powerup, thought the d_in has garbage on it. The d_in
> > turns good when i do the 'blank check' on the CPLD or when I reprogram
> > the CPLD. That's why I'm wondering if the 'blank check' drives the
> > CPLD's pins to 0 or 1 during the 'blank check' operation, something
> > funky like that
>
> > thanks again, any help is much appreciated
>
> You have just described a system and symptom completely unrelated to the
> typical questions devined by the "what happens when I do this" question.
>
> You have a CPLD that doesn't just connect two parts.  You have a CPLD that
> powers up between two parts that power up.
>
> Chances are the prom and FPGA are not both happy.  The blank check for the
> CPLD might do something that functionally changes the I/O.  Typically a
> blank check isn't used to ponder whether an operating device is blank so a
> "destructive" check is reasonable where outputs can tristate or change state
> while the device is interrogated.
>
> Use a logic analyzer or similar device to look at the power-up behavior of
> the PROM control signals as well as the FPGA program control pins.  You
> probably have a misbehavior in the initialization because the CPLD isn't on
> at the right time - or correct power-on polarity - for the attached devices.
>
> Your cure may be as simple as added pull-up/pull-down resistors or a little
> intelligence to make sure both devices around the CPLD are in reset.
>
> The problem isn't around the "blank check" as implied by your initial
> superficial question (no depth) but in the CPLD's behavior in your FPGA
> initialization.


it does surely sound like a powerup issue. BUT - if I knew what
happens to the i/o of the CPLD on a 'blank check' I could put it into
code so the CPLD can perform the same function once it is up and
running.


Article: 116117
Subject: Re: Help with Partial Reconfiguration on Spartan3
From: "salorankatu" <salorankatu@gmail.com>
Date: 1 Mar 2007 11:42:22 -0800
Links: << >>  << T >>  << A >>
Hi Luca,

I think that you are using IMPACT to send the partial bitstreams.
IMPACT sends a command (I do not remember exactly the name) before
sending the bistream that stops all FPGA functionality. To test your
partial bitstreams in Spartan3 while the remainder of you circuit
continues working you have to use the SelectMap/JTAG interface
directly without IMPACT.

Regards,

Ivan

On Mar 1, 1:08 pm, lucaroccasa...@gmail.com wrote:
> Dear all,
>
> I am trying to perform a module based partial reconfiguration on a
> Spartan3 XC3S400 (on a 3SxLC board by MEMEC). I am using ISE
> 8.2.01i_PR_07b (sp1 with Early Access Patch)
> I already was able to perform a difference based partial
> reconfiguration without any problem, but when trying to perform a
> module based reconfiguration, when I download via JTAG the partial
> bitstream it seems that the device reconfigure itself totally: in
> fact, the static part which only switch on and off a led stops
> running.
>
> I created the bitstream from the ISE using these command lines:
> 1) the total bitstream using <bitgen -w top.ncd top.bit>
> 2) the partial ones using <bitgen -g ActiveReconfig:Yes -d -w
> partial.ncd partial.bit>
>
> In the implementing phase I use the following additional options:
> for the TRANSLATE phase <-u -aul>
> for the MAP phase <-u>
>
> Moreover when implementing the partial module synthesis I deasserted
> the option "Add input-output buffers"
>
> Is there someone else I should try?
>
> I tried also to create the bitstream using the pearl script
> (PR_verifydesign and PR_assemble) from the PR patch but I obtained
> some errors. For instance, when I try to merge the static module with
> the reconfigurable one using the PR_verifydesign static.ncd
> dynamic.ncd I obtain the following error
> "ERROR:  Illegal attempt to merge two designs that are not both
> partial".
>
> I hope you can help me. In case you need more information please let
> me know
>
> Luca



Article: 116118
Subject: Re: what does a 'blank check' do exactly
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 1 Mar 2007 11:49:28 -0800
Links: << >>  << T >>  << A >>
<mtsukanov@gmail.com> wrote in message 
news:1172776617.906745.77140@31g2000cwt.googlegroups.com...
>
> it does surely sound like a powerup issue. BUT - if I knew what
> happens to the i/o of the CPLD on a 'blank check' I could put it into
> code so the CPLD can perform the same function once it is up and
> running.

This approach - mimic the blank check - may set you up for failure.  While 
it appears that you operate properly every time you perform the blank check, 
you're not looking at all the possible silicon and operating conditions, 
just what you have in front of you.

Read up on how to power-up or reset the prom properly.
Read up on how the CPLD I/Os behave on power up.
Read up on how to properly program the FPGA.

Implement a system which - by design, not by experiment - is guaranteed to 
work.

If you insist on engineering by enecdote, please at least take a scope probe 
to the CPLD pins and watch what the specific signals do during that blank 
check operation. 



Article: 116119
Subject: Re: what does a 'blank check' do exactly
From: mtsukanov@gmail.com
Date: 1 Mar 2007 11:59:17 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 2:49 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> <mtsuka...@gmail.com> wrote in message
>
> news:1172776617.906745.77140@31g2000cwt.googlegroups.com...
>
>
>
> > it does surely sound like a powerup issue. BUT - if I knew what
> > happens to the i/o of the CPLD on a 'blank check' I could put it into
> > code so the CPLD can perform the same function once it is up and
> > running.
>
> This approach - mimic the blank check - may set you up for failure.  While
> it appears that you operate properly every time you perform the blank check,
> you're not looking at all the possible silicon and operating conditions,
> just what you have in front of you.
>
> Read up on how to power-up or reset the prom properly.
> Read up on how the CPLD I/Os behave on power up.
> Read up on how to properly program the FPGA.
>
> Implement a system which - by design, not by experiment - is guaranteed to
> work.
>
> If you insist on engineering by enecdote, please at least take a scope probe
> to the CPLD pins and watch what the specific signals do during that blank
> check operation.


I completely agree with you. Unfortunately, I didn't design this
'custom' board, so I have to work with what I got, which means almost
all BGA parts: can't probe any line I please - no access to the pin/
trace. But yes it looks like I need to do more 'investigative' work
for sure.


Article: 116120
Subject: Re: XC3S400 and XC3S500E in PQ208
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 1 Mar 2007 20:08:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
Symon <symon_brewer@hotmail.com> wrote:
...
> >
> Hi Uwe,
> I think this is one of those few times where I'm tending 
> to disagree with 
> you. IMHO, the SI properties of the PQ208 package are so
> terrible that any 
> prototype made using a PQ208 containing a die capable of 
> sub-ns rise times 
> is not going to accurately reflect what would happen when
> you build it with 
> a decent FBGA package. Sure the internal logic will work ok,
> but that's what 
> simulators are good at.

Not all applications are bound by outgoing traffic. If you have many
input signals, plenty available Pin are welcome, and SI issues are 
not that big issue...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 116121
Subject: Re: what does a 'blank check' do exactly
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 02 Mar 2007 09:12:12 +1300
Links: << >>  << T >>  << A >>
mtsukanov@gmail.com wrote:
> 
> it does surely sound like a powerup issue. BUT - if I knew what
> happens to the i/o of the CPLD on a 'blank check' I could put it into
> code so the CPLD can perform the same function once it is up and
> running.

That depends on the exact nature of the powerup issue - some aspects of
power cycling,  you cannot 'put into code'.
'blank check' (or verify, or any JTAG read ), will cycle the JTAG state
engine, and exit in a known way, and do so with full Vcc on the devices.

So you may have a sequecing problem.

Don't Xilinx have app notes for using their CPLDs to load FPGAs ?
Try their code ?

-jg


Article: 116122
Subject: Re: XC3S400 and XC3S500E in PQ208
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 02 Mar 2007 09:38:33 +1300
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:

> Symon <symon_brewer@hotmail.com> wrote:
> ...
> 
>>Hi Uwe,
>>I think this is one of those few times where I'm tending 
>>to disagree with 
>>you. IMHO, the SI properties of the PQ208 package are so
>>terrible that any 
>>prototype made using a PQ208 containing a die capable of 
>>sub-ns rise times 
>>is not going to accurately reflect what would happen when
>>you build it with 
>>a decent FBGA package. Sure the internal logic will work ok,
>>but that's what 
>>simulators are good at.
> 
> 
> Not all applications are bound by outgoing traffic. If you have many
> input signals, plenty available Pin are welcome, and SI issues are 
> not that big issue...

  SI covers not just the I/O but also the Vcc/Gnds, as the core switching
currents need to find a low impedance.

  Another wrinkle in the "drop the die into a PQ208" idea, is that
many now use flip chip spread bonding (bond pads over the whole die)
- works very well in BGA, but rather kills using a perihperal bond 
package. Even MLF only gets low Z on the Gnd bondings, and FPGA's
have many supplies.

  Having said that, there is a market for easy to deploy FPGAs (low PCB 
layer count ), and not just lab prototypes. The PC and Hard Drive 
markets are good examples of just how hard-nosed some high volume 
customers are about layer counts.

  If the fpga vendors keep driving up the PCB layer counts,  and MFG 
machinery costs, then they will be doomed to grow at a rate
that is below the fabless industry average. ( Oh, right, that's already 
happening....)

-jg






Article: 116123
Subject: Re: looking for the source VHDL for Jpeg 2000
From: "Frederic" <gnituil@gmail.com>
Date: 1 Mar 2007 12:39:33 -0800
Links: << >>  << T >>  << A >>
On 3=D4=C21=C8=D5, =CF=C2=CE=E77=CA=B100=B7=D6, Sylvain Munaut <tnt-at-246t=
Nt-
dot-...@youknowwhattodo.com> wrote:
> Frederic wrote:
> > Hello,
>
> > I am just looking for the Jpeg 2000 source in VHDL, can anyone help
> > me?
>
> Free ?
> I think you're a little optimistic ;)
>
> And the "paying" cores are $$$ (well, that depends of the speed / profile=
 / ... you need but not cheap).
>
> What application do you have in mind ?
>
>         Sylvain

oki, in fact, I am just looking for an example for architectural
synthesis, because I have applied our tool for AES and Sobel, I want
to try a more big example, I have DWT core in VHDL, and I have no time
to write a jpeg by myself.


Article: 116124
Subject: Re: suggestions for good MPEG encoder dev kit, embedded hard disk dev kit
From: "larwe" <zwsdotcom@gmail.com>
Date: 1 Mar 2007 13:33:26 -0800
Links: << >>  << T >>  << A >>
On Mar 1, 1:44 pm, "wallge" <wal...@gmail.com> wrote:
> I know that I could just send pre-encoded
> video to my FPGA and skip the encoder ASIC
> step, but the whole point of my project is to put together
> an embedded system, which a desktop computer is not part of.
> Or at least proof of concept for an embedded system...

"PC" does not imply "desktop computer". Look at embedded PC solutions
from Advantech, BCM, etc.




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