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 43300

Article: 43300
Subject: Re: virtex 2 block rams
From: shparekh@yahoo.com
Date: 18 May 2002 10:02:09 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CE62C87.9C4C83FE@algor.co.uk>...
> Hal Murray wrote:
> 
> > >I think this is possible if the ratio of portA/portB is a root of 2.
> > >Because, the port size on brams is in power of 2.
> > >Therefore, it works in case of 128(wider port)/32(narrower port) = 4
> > >(# of brams).  i.e. scramble the 96bits in groups of 32(narrower
> > >port)/4(# of brams) = 8 bits.
> > >
> > >In my case, (portA = 96)/(portB = 32) = 3.  This will not work without
> > >going through some hassle which I think will be more than using a mux
> > >or tristate bufs.
> >
> > I don't know how this fits into your tradeoffs, but I think you
> > can make Peter's suggestion work if you are willing to throw away
> > 1/4 of your memory.
> >
> > Write 4x32 bits.  Put garbage or a constant in the top word.
> > When reading, read words 0, 1, 2, but skip over word 3.
> >
Well, that is essentially, what I am doing.  I do not even have to
hook up the 4th block ram.  To keep it convenient the words are
aligned to 128b.  Although, I only use 96b.  And therefore, I do not
really, have the need for the 4th block ram.  But even if I had a 4th
block ram, I cannot scramble the bits using the 4th block ram.

> 
> In that case what we would have for the read side is:
> 
> BRAM address = read_addr / 3
> 
> BRAM select = read_addr % 3
> 
> Maybe I'm thinking of the case where the read address is random though. If
> reading is always sequential then its easy.
> 
> Another approach, if there are 2 clocks available for each write, might be to use
> a 64 bit wide input port:
> 
> input address 0 ->  ram address = 0: words 0, 1
>                               ram address = 1: word 2 into lower
> 
> input address 1 -> ram address = 1: word 0 into upper
>                              ram address = 2: words 1,2
> 
> Then the pattern repeats. For each even/odd pair of input addresses the first ram
> address is
> 
>     3 * (input address/2)
> 
> which can be done either via a lookup table or the Virtex-2 h/w multiplier.
> 
> This approach would be less costly if the input went 128/256 bits wide since then
> a 2 clock write is needed only on 1/2 or 1/4 of the incoming writes.
> 
> Note that if not enough clocks are available at the input speed you could always
> use a DCM to generate a x2 clock (or x1.5 @128 bits or ...).

This certainly seems like a way to solve the problem.  But I am not
sure why this would be better than using a mux or a tristate buffer? 
Not having worked with xilinx devices for long I may not know
something that is obvious to or known by more experienced.

Article: 43301
Subject: Re: HardPath
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sat, 18 May 2002 17:56:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CE68609.658424F0@attbi.com>,
Phil Hays  <SpamPostmaster@attbi.com> wrote:
>So?  A complete test isn't practical.  For example, look at the small
>switch box on the output of a CLB.  Notice that each of the 8 outputs
>from this switch box can be programmed to one of 12 sources.  The number
>of legal combinations is somewhat more than (12*12*12... eight times) or
>12^8 or 429,981,696 different ways to program that switch box.  At 25 ms
>per configuration load, all combinations could be verified in somewhat
>more than 124 days.  The larger switch boxes would take rather longer. 
>A check for interactions between switch boxes much longer still.  You
>simply can't do a complete test, even if you wanted to.

Why do you think Xilinx SUPPORTS partial reconfiguration?  That
hardware wasn't included for the users, but for the test engineers.
I'd personally bet that there are some nice "Reconfigure ALL slices to
the same config" option too, to really speed up testing.

>A shorter than complete test needs to make assumptions that may well be
>very good, but may well miss specific failures.  Understand, I'm not
>looking for perfection.  I'm looking for a better test.  I'd like to buy
>it as an off the shelf option, if I could.  I'd rather buy it from
>Xilinx, but if not there are other options such as a third party test
>house and/or do it in house.

But what probablity do those failures occur:  EG, two WEAK transistors
(instead of dead transistors) which would affect a critical path on
one configuration?

ALso, remember, NOTHING is certain, 100%, in the electronics world: by
the same argument, that CPU you rely on can always be hit by a gamma
ray on one of the internal busses.  You have to settle with some very
low probablity of failure (which can be made arbitrarily low by
various schemes), but is still finite.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 43302
Subject: Re: virtex 2 block rams
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 18 May 2002 18:09:04 -0000
Links: << >>  << T >>  << A >>
> > > Write 4x32 bits.  Put garbage or a constant in the top word.
> > > When reading, read words 0, 1, 2, but skip over word 3.
> > >
> Well, that is essentially, what I am doing.  I do not even have to
> hook up the 4th block ram.  To keep it convenient the words are
> aligned to 128b.  Although, I only use 96b.  And therefore, I do not
> really, have the need for the 4th block ram.  But even if I had a 4th
> block ram, I cannot scramble the bits using the 4th block ram.

If you have 4 RAMs, and you interlace the write bits, then you can
use the muxing in the RAM by reading each RAM 8 bits wide rather than 32.

[I think that's what Peter was suggesting.]

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43303
Subject: Re: Driving high speed external devices from an FPGA
From: Adrian <>
Date: Sat, 18 May 2002 10:16:53 -0800
Links: << >>  << T >>  << A >>
Are you going to drive the DAC with a clock signal from your DLL? You can just use different phase shifted signals until it works and you meet your setup requirements. I would guess either a 180 degree or 270 degree phase shift would work.

adrian

Article: 43304
Subject: Re: virtex 2 block rams
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 18 May 2002 19:19:37 +0100
Links: << >>  << T >>  << A >>


shparekh@yahoo.com wrote:

> Rick Filipkiewicz <rick@algor.co.uk> wrote in message

<snip>

>
> > This approach would be less costly if the input went 128/256 bits wide since then
> > a 2 clock writming writes.
> >
> > Note that if not enough clocks are available at the input speed you could always
> > use a DCM to generate a x2 clock (or x1.5 @128 bits or ...).
>
> This certainly seems like a way to solve the problem.  But I am not
> sure why this would be better than using a mux or a tristate buffer?
> Not having worked with xilinx devices for long I may not know
> something that is obvious to or known by more experienced.

No its my apology time since I missed out one important thing about the BRAMs. The A & B ports
can be configured with different widths! For example if the `A' port is set up to 2Kx9 then the
`B' port can be 2Kx9 [1:1] 1Kx18 [2:1] or 512x36 [4:1] => no mux is needed as long as 4 BRAMs
[16KB] satisfy your storage needs.

Other combinations are possible - see Table 15 in the V-2 manual BRAM section.



Article: 43305
Subject: Signal Fan-out
From: Adrian <>
Date: Sat, 18 May 2002 10:24:05 -0800
Links: << >>  << T >>  << A >>
Hi,

Could anyone point me to a reference on fanning out signals to multiple FPGA's. I want to fan out 2x6bit signals to seven Spartan II's at 32MHz, but my ADC from where the signals are being fanned from can only source up to 20mA. 

Anyone have any ideas? What kind of current will a Spartan II draw per pin?

thanks
adrian

Article: 43306
Subject: button & 3 LED's
From: "cfk" <cfk_alter_ego@pacbell.net>
Date: Sat, 18 May 2002 19:10:48 GMT
Links: << >>  << T >>  << A >>
I have a board with a VirtexE on it and with amongst other things, a button
(call it USER_IN) and three leds (call then LED[2:0]) controlled by a
variable lstate. I want to create a modest state machine so that I
initialize lstate to 3'b000, and then with each button push, I move to
3'b001..3'b111 and then back to 3'b000. I tried the following:


always @(posedge clk and USER_IN)
    begin
        lstate = lstate + 1;
    end

But what seems to happen is the states are cycling through at clk speed. The
reason I could not use (posedge clk and posedge USER_IN) is then the Xilinx
ISE wants to assign USER_IN to a clock pin and I cannot implement the
design. Maybe this issue is my understanding of ISE and Verilog as I am
officially a newbie at this time.

Next I tried

always @(posedge clk and USER_IN)
    begin: ledstater
        reg lstate_toggle;
    if(USER_IN & lstate)
        begin
            lstate_toggle = !lstate_toggle;
            lstate = lstate + 1;
        end
    end

This one doesn't seem to do anything to the LED's (which are set with a
seperate assign statement). So, any suggestions would be greatly
appreciated.

Charles



Article: 43307
Subject: Re: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 18 May 2002 20:11:26 +0100
Links: << >>  << T >>  << A >>


Kevin Brace wrote:

>
>
>         Here is how I solved the problem.
> I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but
> I guess it doesn't matter.) which also comes with XST to my computer
> where I already got ISE WebPACK 4.2.
> I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF
> file instead of an encrypted .NGC file (The XST since ISE 4.1 does so,
> unfortunately.), so I will manually edit the netlist to duplicate FFs.
> The result is, when I tested it, NGDBUILD correctly read my PCI IP core
> in a netlist, and MAP correctly pushed FFs I duplicated by hand into
> IOBs.
> The only problem is, it takes about 2 to 3 hours to duplicate all 95 or
> so FFs by hand, using a text editor, but that's much better than not
> being able to edit an encrypted netlist (.NGC file) at all.
>

I really and truely don't understand the decision to change from an
``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one
esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to
have to be able to handle it.

The only thing I can come up with is the possibility that someone somewhere
might write a ``technology retargeting'' tool and thus gain a free
synthesiser for their architecture. However the EDIF file has a lot of
technology optimisations specific to Xilinx [and even to a particular Xilinx
device *family* ] built in so I'd say the QOR from this process wouldn't
show the other technology in a very good light unless it was architecturally
very close to Xilinx's ... at which point synth tools would be irrelevant as
the case would already be in the hands of the patent lawyers.

Anyone from Xilinx prepared to confirm that this is the reason ?


Article: 43308
Subject: Xilinx 4000XLA-8: is 4 stages of logic ok?
From: "Songqing Zhang" <szhang8@lucent.com>
Date: Sat, 18 May 2002 11:15:52 -0800
Links: << >>  << T >>  << A >>
Hi, I'm improving the design of a Xilinx 4062XLA BG432 device. It is running at 50Mhz, and I try to do the following 4 stage logic in 1 cycle:

4 bit adder
4-1 mux
32 bit wide, 16 deep dual port ram
4-1 mux

Can I make it?

Thanks

Article: 43309
Subject: Re: Xilinx 4000XLA-8: is 4 stages of logic ok?
From: "Songqing Zhang" <szhang8@lucent.com>
Date: Sat, 18 May 2002 11:17:53 -0800
Links: << >>  << T >>  << A >>
I mean

the first stage is 
4 bit adder (no overflow bit is needed)

2nd stage is 4-1 MUX

3rd stage is 32 bit wide, 16 deep DPRAM (block ram),

4th stage is another 4-1MUX.

Can I do it?

Thanks

Article: 43310
Subject: Re: Bidirectional DONE?
From: "cfk" <cfk_alter_ego@pacbell.net>
Date: Sat, 18 May 2002 19:39:06 GMT
Links: << >>  << T >>  << A >>
Actually, I have a similar need, so let me pose the original posters
question in a different way. It is sometimes necessary to have user logic
initialize in a known state from power up. Perhaps the GSR signal might be
more appropriate (I can see it used in some modules in unisim), but so far,
I have been unable to get past "unresolved reference to GSR or glbl.GSR"
either in my ISE or Modelsim. I have tried compiling glbl.v in (I am working
in verilog) to no avail. So, how does one find a way to let some user code
run once??

Charles

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3CE3D32C.1F877C05@xilinx.com...
> Stephanie,
>
> Internally, when in chains of FPGAs, the DONE pin of the master waits to
> see the DONE pin of the last slave go high (hence it is an input in that
> mode).
>
> Basically, no user logic can operate until DONE goes high, so I don't see
> why you need this.  As soon as DONE goes high, all initial register
> values, FF states, BRAM contents, etc are all present, and on the next
> user supplied system logic clock, everything starts marching along.
>
> Austin
>
> Stephanie McBader wrote:
>
> > Hi,
> >
> > Xilinx FPGA datasheets (both Virtex & Spartan) indicate that the DONE
> > pin is bidirectional. Does that mean that the logic configured inside
> > the FPGA will be able to read it?
> >
> > i.e., would a controller implemented in the FPGA be able to read the
> > value of DONE & say, remains in reset until DONE is asserted?
> >
> > Thanks!
> >
> > Stephanie McBader
> > Researcher/Design Engineer
> > NeuriCam S.p.A
> > Via S M Maddalena 12
> > 38100 Trento TN, Italy
> > Tel: +39-0461-260552
> > Fax: +39-0461-260617
>



Article: 43311
Subject: Re: HardPath
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sat, 18 May 2002 21:03:47 GMT
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
 
> In article <3CE68609.658424F0@attbi.com>,
> Phil Hays  <SpamPostmaster@attbi.com> wrote:
>> So?  A complete test isn't practical.

> I'd personally bet that there are some nice "Reconfigure ALL slices to
> the same config" option too, to really speed up testing.

An interesting speculation, however it doesn't change the issue much. 
The tiny output switch box might be tested faster by several orders of
magnitude by such methods, but Xilinx can't afford to spend more a day
testing just that part of the device, or even a hour.  Tester time on
big part testers isn't cheap: fifteen years ago we figured on about US$
0.25 per second, and while I've been out of that end of the business
since then I doubt if it has gotten cheaper.  The output switch box is
much smaller, meaning much easier to test, than the input switch box or
the routing switch box.  To fully test the interaction between switch
boxes is probably longer than the age of the Universe.


> >A shorter than complete test needs to make assumptions that may well be
> >very good, but may well miss specific failures.  Understand, I'm not
> >looking for perfection.  I'm looking for a better test.  I'd like to buy
> >it as an off the shelf option, if I could.  I'd rather buy it from
> >Xilinx, but if not there are other options such as a third party test
> >house and/or do it in house.
> 
> But what probablity do those failures occur:  EG, two WEAK transistors
> (instead of dead transistors) which would affect a critical path on
> one configuration?

Josh's estimate from last year was about 1 in 50 parts had an undetected
defect.

http://groups.google.com/groups?hl=en&lr=&selm 010731.103308.1239036029.24248%40polybus.com

The parts in question are of similar manufacturing date.


> ALso, remember, NOTHING is certain, 100%, in the electronics world: by
> the same argument, that CPU you rely on can always be hit by a gamma
> ray on one of the internal busses.  You have to settle with some very
> low probablity of failure (which can be made arbitrarily low by
> various schemes), but is still finite.

I'm not looking for certainty, I'm looking for better odds.  The
probability of failure can be lowered by getting a more complete test,
which probably does not make economic sense for the majority of users.


-- 
Phil Hays

Article: 43312
Subject: Re: Signal Fan-out
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 18 May 2002 21:19:19 GMT
Links: << >>  << T >>  << A >>
Current is  not the issue. At a guaraneted max input current of 10 microamps, you could drive a fan-out of twothousand!
Delay is the issue. How much capacitance are you driving?
For a very rough approximation assume each input to be 10 pF, double or triple that for the pc-board traces, and assume a 20 Ohm output impedance.
At seven loads times 40 pF, you get a time constant of 5.6 ns ( very pessimistically). This ignores signal integrity issues like reflections etc.
Can you live with a 5 to 10  ns delay?

Peter Alfke, Xilinx Applications.
===================
Adrian wrote:

> Hi,
>
> Could anyone point me to a reference on fanning out signals to multiple FPGA's. I want to fan out 2x6bit signals to seven Spartan II's at 32MHz, but my ADC from where the signals are being fanned from can only source up to 20mA.
>
> Anyone have any ideas? What kind of current will a Spartan II draw per pin?
>
> thanks
> adrian


Article: 43313
(removed)


Article: 43314
Subject: Re: Need Help on FPGA and Spiking Neurons
From: Micah Dowty <micahjd@users.sourceforge.net>
Date: Sat, 18 May 2002 21:28:48 GMT
Links: << >>  << T >>  << A >>
On Thu, 16 May 2002 20:45:53 -0600, rickman wrote:

> you need to design in a level of programmable interconnect that may make
> the problem a bit more complex.

What about using the FPGA's existing interconnect, and changing the
connections betweeen neurons using partial reconfiguration?

Article: 43315
Subject: Re: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 18 May 2002 17:09:50 -0500
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> 
> I really and truely don't understand the decision to change from an
> ``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one
> esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to
> have to be able to handle it.
> 


        One problem of an encrypted netlist is that I cannot see if the
synthesis tool is correctly synthesizing the design.
Recently, I saw XST 'dropping' valid FFs used in a design.
It took me two days to figure out what was going on, and I found the
problem only when I synthesized the design with an old XST that
generated an EDIF netlist.
        I can see that Xilinx wanting to have an encrypted netlist for
LogiCORE IP cores or COREgen IP cores because otherwise, users can
easily do an FPGA-to-ASIC conversion, but I feel like it is none of
Xilinx's business to restrict how I deal with a netlist generated by
XST.




> The only thing I can come up with is the possibility that someone somewhere
> might write a ``technology retargeting'' tool and thus gain a free
> synthesiser for their architecture. However the EDIF file has a lot of
> technology optimisations specific to Xilinx [and even to a particular Xilinx
> device *family* ] built in so I'd say the QOR from this process wouldn't
> show the other technology in a very good light unless it was architecturally
> very close to Xilinx's ... at which point synth tools would be irrelevant as
> the case would already be in the hands of the patent lawyers.
> 
> Anyone from Xilinx prepared to confirm that this is the reason ?


        Although I am not from Xilinx, one thing I noticed when I saw
the EDIF netlist generated by XST was that the primitives used by the
EDIF netlist looked like similar primitives that Altera's LUT-based
devices (i.e., FLEX, APEX, and Stratix) have.
I know that Altera devices don't have an F5MUX, but I think that can be
emulated with a regular 4-input LUT.
However, for about $10K, anyone can buy a synthesis tool (Synplify or
LeonardoSpectrum) that can generate an EDIF file that targets Xilinx or
Altera devices, so I am not sure if it makes much sense to create such a
conversion tool.




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 43316
Subject: Re: button & 3 LED's
From: Ray Andraka <ray@andraka.com>
Date: Sat, 18 May 2002 22:13:07 GMT
Links: << >>  << T >>  << A >>
Mechanical switches bounce, meaning that there is not a clean 0 to 1 or 1 to 0
transition.  Instead, the switch actually opens and closes hundreds of times
within a few milliseconds.  A bouncing switch can make your state machine think
it is getting lots of button pushes within a short time, which, if observed on
the LEDs could give the illusion that the state machine is not stepping properly
when in fact it is (but going too fast to observe with your eyes).

In order to use a switch as an input to a logic circuit,the logic circuit needs
to include a switch debouncer, which is essentially a filter.  A simple
debouncer can be made with a counter and a 4 state state machine:

case state is
    s0:
        reset counter
        state<=s0 if switch=0, else s1
        debounced out = 0
    s1:
        enable counter
        state<=s0 if switch=0 else s1 if count_TC=0 else s2
        debounced out = 0
    s2:
        reset counter
        state<=s2 if switch=1 else s3
        debounced out = 1
    s3:
        enable coutner
       state<=s2 if switch=1 else s3 if count_TC=0 else s0
        debounced out = 1

The counter should be long enough to not expire before the bounce time spec of
the switch (several milliseconds).  For your state machine, you need to detect
the edge of the debounced switch signal (synchronous detection uses a flip-flop
to delay the debounced signal and a gate to sense when the debounced and
debounced delayed signals don't match).  The edge detected signal can advance
your state machine.  The debounce, edge detection and your state sequence can,
of course be combined into one state machine.


cfk wrote:

> I have a board with a VirtexE on it and with amongst other things, a button
> (call it USER_IN) and three leds (call then LED[2:0]) controlled by a
> variable lstate. I want to create a modest state machine so that I
> initialize lstate to 3'b000, and then with each button push, I move to
> 3'b001..3'b111 and then back to 3'b000. I tried the following:
>
> always @(posedge clk and USER_IN)
>     begin
>         lstate = lstate + 1;
>     end
>
> But what seems to happen is the states are cycling through at clk speed. The
> reason I could not use (posedge clk and posedge USER_IN) is then the Xilinx
> ISE wants to assign USER_IN to a clock pin and I cannot implement the
> design. Maybe this issue is my understanding of ISE and Verilog as I am
> officially a newbie at this time.
>
> Next I tried
>
> always @(posedge clk and USER_IN)
>     begin: ledstater
>         reg lstate_toggle;
>     if(USER_IN & lstate)
>         begin
>             lstate_toggle = !lstate_toggle;
>             lstate = lstate + 1;
>         end
>     end
>
> This one doesn't seem to do anything to the LED's (which are set with a
> seperate assign statement). So, any suggestions would be greatly
> appreciated.
>
> Charles

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

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



Article: 43317
Subject: Re: Bidirectional DONE?
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 18 May 2002 22:13:57 -0000
Links: << >>  << T >>  << A >>
>Actually, I have a similar need, so let me pose the original posters
>question in a different way. It is sometimes necessary to have user logic
>initialize in a known state from power up. Perhaps the GSR signal might be
>more appropriate (I can see it used in some modules in unisim), but so far,

This gets discussed here occasionally.

An important thing to consider is that the timing on GSR is very slow.
It's essentially an asynchronous signal.  (Been there. Don't need
another lesson.)

Best suggestion is to have a local FF that gets reset by GSR and
use it to reset your state machine.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43318
Subject: Re: Anyody else get spam about "FPGA Video Seminar"?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 18 May 2002 17:14:49 -0500
Links: << >>  << T >>  << A >>

Hal Murray wrote:
> 
> 
> That's the sort of response I got when I asked them where they
> got my email address.  (I'm pretty sure they harvested it from
> here.)
> 
> Anybody read/view the video?  What company are they pushing?
> Anybody got any contacts in their marketing dept? ...
> 


        I got the same sapm you are talking about, so whoever idiot got
the E-mail addresses from this newsgroup.
I didn't feel like rewarding them by visiting their website, so I
immediately trashed the spam.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 43319
Subject: Re: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: Ray Andraka <ray@andraka.com>
Date: Sat, 18 May 2002 22:16:18 GMT
Links: << >>  << T >>  << A >>
While I don't know if this the case here, a good reason for an encrypted netlist
is to protect IP.  The open format of the EDIF netlist with no means of
encrypting it is a major hindrance to those wishing to sell IP.

Rick Filipkiewicz wrote:

> Kevin Brace wrote:
>
> >
> >
> >         Here is how I solved the problem.
> > I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but
> > I guess it doesn't matter.) which also comes with XST to my computer
> > where I already got ISE WebPACK 4.2.
> > I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF
> > file instead of an encrypted .NGC file (The XST since ISE 4.1 does so,
> > unfortunately.), so I will manually edit the netlist to duplicate FFs.
> > The result is, when I tested it, NGDBUILD correctly read my PCI IP core
> > in a netlist, and MAP correctly pushed FFs I duplicated by hand into
> > IOBs.
> > The only problem is, it takes about 2 to 3 hours to duplicate all 95 or
> > so FFs by hand, using a text editor, but that's much better than not
> > being able to edit an encrypted netlist (.NGC file) at all.
> >
>
> I really and truely don't understand the decision to change from an
> ``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one
> esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to
> have to be able to handle it.
>
> The only thing I can come up with is the possibility that someone somewhere
> might write a ``technology retargeting'' tool and thus gain a free
> synthesiser for their architecture. However the EDIF file has a lot of
> technology optimisations specific to Xilinx [and even to a particular Xilinx
> device *family* ] built in so I'd say the QOR from this process wouldn't
> show the other technology in a very good light unless it was architecturally
> very close to Xilinx's ... at which point synth tools would be irrelevant as
> the case would already be in the hands of the patent lawyers.
>
> Anyone from Xilinx prepared to confirm that this is the reason ?

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

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



Article: 43320
Subject: Re: HardPath
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 19 May 2002 10:29:55 +1200
Links: << >>  << T >>  << A >>
Phil Hays wrote:
> 
<snip> 
> I'm not looking for certainty, I'm looking for better odds.  The
> probability of failure can be lowered by getting a more complete test,
> which probably does not make economic sense for the majority of users.

 Sounds like a candidate for hard drive style 'bad sector' 
mapping (future), and also for some ability to 'seed' the 
P&R tools to deliberately use other resource : that way, 
if you suspect a HW node issue, roll the dice again, and re-check. 
 Easier than replace of FPGA, or even multiple PCBs, esp at prototype
stages.
Of course, 99.9% of the time, it will be 'cockpit error'...

-jg

Article: 43321
Subject: Re: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 18 May 2002 22:46:56 -0000
Links: << >>  << T >>  << A >>
>While I don't know if this the case here, a good reason for an encrypted netlist
>is to protect IP.  The open format of the EDIF netlist with no means of
>encrypting it is a major hindrance to those wishing to sell IP.

But that gets you into the key distribution business which might
be OK for IP, but sounds ugly for normal use.

Security-by-obscurity is known not to work. It will just encourage
the bad guys and annoy the good guys.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43322
Subject: Re: Need Help on FPGA and Spiking Neurons
From: Traveler <eightwings@hotmail.com>
Date: Sat, 18 May 2002 23:03:35 GMT
Links: << >>  << T >>  << A >>
In article <3CE66E6E.16FD92D8@andraka.com>, Ray Andraka
<ray@andraka.com> wrote:

>OK, I didn't realize you were using 1 bit models.  When I dabbled with
>neural nets a few years ago, the synapses carried a number to represent
>analog behavior, hence there was arithmetic and logic to implement the
>linear and non-linear behavior.  In any event, your neuron still needs some
>logical function, perhaps a sum and binary threshold.  I was referring to
>the model of the neuron.  Mine used a fixed connection network with the
>strengths of the connections determined by the learning, where you
>apparently want to actually make or break the connections.  You might look
>at block memories as the connection matrix.

Thanks for the reply. All signals in my network are 1-bit discrete
signals.  I use several types of neurons and synapses.  The neurons I
use are spiking neurons: the arrival times of input signals are what
decides whether or not a neuron fires, at least in most neurons. My
synapses also have a connection strength that can be represented by an
integer.  The strength of some synapses is decremented by 1 every time
they fire. In other neurons it is incremented.  If the target neurons
fires, synapses that contributed to the firing are strongly
strengthened. The others are strongly weakened.  Each neuron type has
its own firing function that depends on the arrival times of input
signals.  Some neurons are coincidence detectors while others are
sequence detectors.

I am reasonably sure all these things can be accomplished using FPGA
technology.  What I am not sure about is whether one can use an
FPGA-based network that has the ability to make an indefinite number
of input and output connections between some neurons, (say, up to 200
connections).  Can you elaborate a little on your suggestion to use
block memories as the connection matrix?

Temporal Intelligence:
http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htm

Article: 43323
Subject: Re: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 18 May 2002 18:35:04 -0500
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> While I don't know if this the case here, a good reason for an encrypted netlist
> is to protect IP.  The open format of the EDIF netlist with no means of
> encrypting it is a major hindrance to those wishing to sell IP.
> 


        Because it is so easy to convert an EDIF netlist to an encrypted
.NGO file in Xilinx's software, I have been thinking of licensing
(selling) my PCI IP core as an encrypted netlist when it is done.
However, does anyone know how I can do something similar in Altera's
tools?
LeonardoSpectrum-Altera generates an EDIF file, which is fine, but it
will be nice if I can somehow encrypt it.
        Speaking of protecting IP cores, even a .NGO file is probably
not terribly safe considering that someone who doesn't want to pay for
it can easily get a copy from someone else.
I suppose the only value of a .NGO file is to prevent an FPGA-to-ASIC
conversion by companies like Lightspeed Semiconductor or AMI
Semiconductor.
However, in Altera's IP core program, I believe the user has to buy
(license) a key to program their devices, so just getting a copy of an
encrypted netlist from someone will probably not do any good.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 43324
Subject: Slice Usage Per Module
From: "Kevin Neilson" <kevin-neilson@removethistextattbi.com>
Date: Sun, 19 May 2002 00:23:48 GMT
Links: << >>  << T >>  << A >>
The Xilinx mapper reports total component usage (slices, BRAMs, DCMs, etc.),
but how do I get a breakdown on a per-module basis?
-Kevin





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