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 112450

Article: 112450
Subject: Re: 8080 FSGA model in an FPGA
From: scott moore <nospam@nowhere.com>
Date: Wed, 22 Nov 2006 07:21:15 -0800
Links: << >>  << T >>  << A >>
http://zone.ni.com/devzone/cda/tut/p/id/3953
http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm

Using surface mount and low current, the machine would be about the
size of a refrigerator, and fairly slow, but workable. I doubt
these small reed relays would even make a noise.

Its the "fortune" rule. Someone, somewhere makes it, and does it modern.
There are still buggy whips made somewhere, you just have to look.

rickman wrote:
> Grant Stockly wrote:

>>
>> I really want to build a computer from relays, and even priced out some
>> nice ones on e-bay, but I am concerned about how long it would last
>> before failing...
> 
> One type of computer that might actually be interesting to build of
> relays and operate would be a time piece.  To keep the power
> consumption down, you might use latching relays.  The contain a
> permanet magnet that holds the contact in either state and a pulse from
> the coil is required to change the state.  Each relay is then a FF.
> The logic would be done by stringing relays in series or parallel to
> form AND and OR functions (with or without inversions).  You could also
> use diodes to form the logic if you want to save some space.  There are
> some fairly minature relays available at around $5 or less.  We are
> using some latching RF relays at that price.  They are about 15 x 10 mm
> so a clock circuit might take up a square foot depending on the
> density.  It would also tick every second with major noises on the
> minutes and hours.
> 
> I am working on a relay controller circuit for an RF module and when I
> do the test code, it will have a few options to sound out tap dancing
> like music.  That should prove interesting and entertaining!
> 

Article: 112451
Subject: Aurora and Chipscope
From: "nana" <nmichou@utk.edu>
Date: 22 Nov 2006 07:24:36 -0800
Links: << >>  << T >>  << A >>
Hi,
I am using aurora software to create a core to move data from the pc to
xupv2p board to another xupv2p board and I am using Chipscope to
monitor the signal.
When I launch chipscope inserter and go to connect the signal names I
can't figure out what names to use, there are so many of them, ie I
don't know what most of them mean.
Also, the aurora core creates a folder (examples) with three files
(aurora_sample.vhd, frame_check.vhd and frame_gen.vhd), I assume frame
generator is supposed to generate some data to be transferred between
the two boards but I can't see it in chipscope.
I used a pre-designed project and it showed me the data (tx_d_i_2 and
rx_d_i_1), but when I use my design I do'nt see any data except when I
open the pre-designed file (aurora_link_cs.cpj) into my design then I
can see data.
Can anybody tell me what to do here?
I appreciate all help

Nathan


Article: 112452
Subject: Re: 8080 FSGA model in an FPGA
From: scott moore <nospam@nowhere.com>
Date: Wed, 22 Nov 2006 07:28:11 -0800
Links: << >>  << T >>  << A >>
http://web.cecs.pdx.edu/~harry/Relay/

Why anyone would use those big relays and point to point wiring is
beyond me.

http://www.vaxman.de/my_machines/phywe/pgr/pgr.html
http://www.electronixandmore.com/project/relaycomputer/index.html

What have we learned? There are people with WAY too much time on their
hands :-)

scott moore wrote:
> http://zone.ni.com/devzone/cda/tut/p/id/3953
> http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm
> 
> Using surface mount and low current, the machine would be about the
> size of a refrigerator, and fairly slow, but workable. I doubt
> these small reed relays would even make a noise.
> 
> Its the "fortune" rule. Someone, somewhere makes it, and does it modern.
> There are still buggy whips made somewhere, you just have to look.
> 
> rickman wrote:
>> Grant Stockly wrote:
> 
>>>
>>> I really want to build a computer from relays, and even priced out some
>>> nice ones on e-bay, but I am concerned about how long it would last
>>> before failing...
>>
>> One type of computer that might actually be interesting to build of
>> relays and operate would be a time piece.  To keep the power
>> consumption down, you might use latching relays.  The contain a
>> permanet magnet that holds the contact in either state and a pulse from
>> the coil is required to change the state.  Each relay is then a FF.
>> The logic would be done by stringing relays in series or parallel to
>> form AND and OR functions (with or without inversions).  You could also
>> use diodes to form the logic if you want to save some space.  There are
>> some fairly minature relays available at around $5 or less.  We are
>> using some latching RF relays at that price.  They are about 15 x 10 mm
>> so a clock circuit might take up a square foot depending on the
>> density.  It would also tick every second with major noises on the
>> minutes and hours.
>>
>> I am working on a relay controller circuit for an RF module and when I
>> do the test code, it will have a few options to sound out tap dancing
>> like music.  That should prove interesting and entertaining!
>>

Article: 112453
Subject: Re: Spartan 3E-Kit
From: spartanius@arcor.de
Date: 22 Nov 2006 07:36:17 -0800
Links: << >>  << T >>  << A >>

I am currently using the ISE 8.1 - you seem to use 8.2. Could this be
the explanation for the errors?

Anyway, I installed the newest available version now, and still have no
success. rightclicking the *.ise opens the ISE, but I have no sources
and have to add them manually again like before.

It seems to be a challenge to get a Xilinx Environment run. (?)  Well,
when starting with Altera`s, 2 years ago, everything worked fine the
first run (eval board board, first project, quartus ide etc).

Hm....

Maybe I am a bit to lazy, or missed  something important, or I am
simply to strong on the Altera line to switch easily.

In any case I am a bit disappointed, that there are no simple and
working examples in a -> starter kit.

Anybody else working with this kit ?


Article: 112454
Subject: Re: Virtex 4 Internal Tristate (BUFT)?
From: "=?utf-8?B?R2FMYUt0SWtVc+KEog==?=" <taileb.mehdi@gmail.com>
Date: 22 Nov 2006 08:03:25 -0800
Links: << >>  << T >>  << A >>
Hi,
There are no BUFT in Virtex-4 because of their big delays. Use
multiplexers instead.

Best Regards

On Nov 22, 5:21 pm, Koen Van Renterghem <Ih8teS...@intec.ugent.be>
wrote:
> Hello,
>
> I was just browsing the Xilinx Libraries Guide pdf in search of BUFT
> component. However, it is not mentioned anymore in the 'Virtex 4
> Libraries Guide for HDL designs'. I was looking into them to optimize
> wide muxes and a bus traversing the complete FPGA fabric.
> Are tristates left out of the Virtex4? Is there an alternative? What
> could be the motivation for such an architectural change?
> 
> Best Regards,
> Koen.


Article: 112455
Subject: Re: board - T562.jpg
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 22 Nov 2006 08:34:16 -0800
Links: << >>  << T >>  << A >>
On 22 Nov 2006 04:58:55 -0800, "rickman" <gnuarm@gmail.com> wrote:

>John Larkin wrote:
>> On 21 Nov 2006 20:14:43 -0800, "rickman" <gnuarm@gmail.com> wrote:
>>
>> >John Larkin wrote:
>> >> We just solved a nasty problem with this:
>> >>
>> >> A d-flop: D tied high; clocked from a pin, CE from internal gating
>> >> logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a
>> >> delay line back into its own async clear. When the input pin rises, if
>> >> CE permits, it makes a single clock pulse. Everything downstream is
>> >> "synchronous" in that it's clocked from this gadget.
>> >>
>> >> The delay line is a chain of AND gates (with transparent latches
>> >> enabled in the logic cells, just to add a little more delay), with
>> >> each fed from the ff Q and also from the previous gate. This is a
>> >> delay line with a fast discharge mechanism when its input goes low, so
>> >> we don't have to wait for the 0 to propagate through, chasing the 1.
>> >
>> >How do you synchronize the input clock with the internal CE signal?  If
>> >it is not synchronized, couldn't you get nasty splinter pulses?
>>
>> The gate signal is totally async to the clock. We're sort of hoping
>> that the output of the logic block is either going to go high or not.
>> A metastability glitch within a Spartan3 flip flop is (optimistically)
>> narrower than the inter-cell routing can propagate. We'll have to try
>> that and see. I could put setup and hold time requirements on the
>> trigger gate specs, and make it the customer's problem!
>>
>> >How do you control the timing of the delay line?  Is the timing window
>> >that you can work in pretty wide?
>>
>> The downstream logic has to work at 80 MHz max. So if we
>> experimentally tune the BUFG output width to, say, 4 ns, we should
>> have a pretty good margin both ways. Most silicon processes seem to be
>> pretty stable these days.
>>
>> I suppose we could make the delay tunable through a register our uP
>> could write, and we could check a test point now and then to make sure
>> we have it right. Just a mux selecting delay-line taps would work. We
>> only need to do this once in the product, and it's important, so this
>> is worth some hassle. The trick is, I suppose, to only take risks when
>> you really need to.
>
>I'm not sure I understand your problem, so I'll ask a few more
>questions.  What is the speed of the clock in the design?  How often
>does the internally clocked CE signal gate the external signal to
>generate a clock pulse?  If the external signal will not generate a
>clock edge on every internal clock there might be an easier way to do
>this that does not depend on timing delays.  It can generate a clock
>enable signal that is asserted on every other clock cycle.  But this
>may or may not work for your application.

The product is a digital delay generator. Given a customer trigger, it
generates four pulses, each programmable for delay and width from the
trigger. There are three clock nets on the chip:

1. Trigger, qualified by a separate gate signal, firing this one-shot.
This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This
drives a bunch of logic, including optional gate/countdown/burst
logic, all of which starts...

2. A non-continuous delay-generator clock. Following the trigger, we
start a gated 50 MHz oscillator that's used to time out 8 coarse
delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip
analog fine delays trim the actual edges to 10 ps resolution. This 50
MHz clock is phase-locked to...

3. A 40 MHz clock, from a TCXO.

A digital PLL thing longterm locks the customer-triggered 50 MHz clock
to the local 40 MHz crystal oscillator but keeps the 50 MHz thing
phase-coherent to the customer trigger, so the delay outputs don't
jitter.

Given all these clocks, and all the signals making multiple passes on
and off the chip, we're getting output jitters in the ballpark of 50
ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8
ps range, but their critical paths are power-hogging PECL.

Generating accurate, low-jitter delays from a random trigger, but with
crystal-oscillator accuracy, is an interesting problem in general, and
it's been approached a lot of ways. We think ours is nicely suited to
implementing in an FPGA with minimal external stuff. Our main
limitation seems to be on-chip crosstalk and maybe a bit of ground
bounce.

John



Article: 112456
Subject: Re: Protecting netlist for Xilinx
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 22 Nov 2006 08:41:21 -0800
Links: << >>  << T >>  << A >>
Sylvain,

Protecting IP is one issue.  Providing a means for IP developers to be 
paid for the use of their IP is another problem (and different).  Using 
multiple IP from multiple vendors, and all getting paid is yet a third 
problem.

As you point out, today there are few good ways (really none) to do any 
of the above.

There is AES256 encryption and decryption in V4 and V5 which provides a 
FIPS-140 compliant solution for the protection of the IP.

But the encrypt/decrypt is not authentication, so it does not help you 
get paid for your work, it just keeps it a secret.

In Virtex 5, we have provided for decrypting AND reconfiguration, so 
that you may load multiple encrypted bitstreams (all using the same 
key), but again, this does not provide a model for IP 'per use' 
payments.  It does allow for secure crypto solutions for applications 
like SDR.

It is a tough problem, and one we would like to solve (obviously).

The use of physically unique coding function (known as PUF codes) would 
allow each device to uniquely be matched to a bitstream (only that 
bitstream can work with that device), but this requires each bitstream 
to be unique for that part.  That doesn't help you, unless the customer 
emailed you their PUFs and AES256 key and you emailed back the matching 
(partical) bitstreams.

Challenge response systems (like RSA) are very complex, and would use a 
lot of silicon.  We would also need a battery backed local session key 
store of about 4 Kb.

This is a topic where there is a lot of opportunity for innovations.

Obfuscation (keeping a secret by keeping secrets) should never be 
considered secure, as paying someone in the parking lot is all it takes 
to crack it.  Keeping your algorithm a secret is equally dumb, as most 
"clever" and "secret" functions are easily cracked (since they have had 
no serious peer cypto review).

Anyone who claims security by obscurity is just ignorant (and dangerous)!

Austin

> Hello,
> 
> I'm working for a company that sell FPGA IP in netlist form.
> I'd like to protect theses IP as much as I can, to try to make
> it as hard as possible to RE them. I know I can't possibly
> fully protect them, but that doesn't mean it doesn't worth trying.
> 
> I've already used the "secure netlist" option of the Xilinx tools,
> but it's not that secure. Also, the net names stays the same.
> So I'm looking at an obfuscating tool that would rename
> all net/instances for me. And also other methods you might
> know ?
> 
> Thanks,
> 
>  Sylvain
> 

Article: 112457
Subject: Re: Simple questions on IDELAYCTRL
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 22 Nov 2006 08:46:07 -0800
Links: << >>  << T >>  << A >>
I tried the same tests setting the DCM to D=1 M=4, D=2 M=8 and setting
the CLKIN_DIVIDE_BY_2 to TRUE then using D=1 and M=8.  All seem to
cause problems with the IDELAYCTRL.

I then took the RF generator (via the PECL driver) and used it to drive
the DCM.

Running the RF generator at 200MHz and using the CLK0 to drive the
IDELAYCTRL appears to work fine (delay per tap seems correct).

Running the RF generator at 50MHz and driving the DCM but using D=1 M=4
and the CLKFX out does not seem to work.

Running the RF generator at 100 MHz then using a D=1 M=2, CLKFX out
appears to work.

Running the RF generator at 200 MHz then using a D=2 M=2, CLKFX out
appears to work.

Austin had published a note about using a 66MHz clock with the DCM set
to D=1 M=3 and having it work.

"The Ref Clock may be supplied from any +/- 10% 200 MHz source,
including
the DCM CLKFX output.  For example, if there is a 66 MHz clock, a M=3,
D=1 will provide you with a ~ 200 MHz output on CLKFX.  There is no
need
to be concerned with the jitter from the CLKFX, as the analog locked
loop which controls the delay is effectively a PLL which filters out
the
high frequency jitter components (jitter on Refclk is attenuated when
transfered to the data lines)."

I tried this same test and it appears not to work (I see that same
200pS / tap).

It seems to be related to how many multiplier stages used in the DCM.

Has anyone else seen this?


Article: 112458
Subject: Re: Virtex 4 Internal Tristate (BUFT)?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 22 Nov 2006 16:55:07 GMT
Links: << >>  << T >>  << A >>
"Koen Van Renterghem" <Ih8teSpam@intec.ugent.be> wrote in message 
news:ek1id8$nng$1@gaudi2.UGent.be...
> Hello,
>
> I was just browsing the Xilinx Libraries Guide pdf in search of BUFT
> component. However, it is not mentioned anymore in the 'Virtex 4
> Libraries Guide for HDL designs'. I was looking into them to optimize
> wide muxes and a bus traversing the complete FPGA fabric.
> Are tristates left out of the Virtex4? Is there an alternative? What
> could be the motivation for such an architectural change?
>
> Best Regards,
> Koen.


The internal tristates have been gone for a while.  Other dedicated 
resources do a better job even for extremely wide busses.  Many designs 
didn't use the slower, dedicated tristates in the older generation parts so 
why keep designing the little-used functionality when the generic device 
provides a better solution?

If you're using HDL, you can still implement tristate logic internal to your 
chip (assigning a driven value or z across your bits) and the synthesis will 
do the translation to multiplexers for you.  No primitive needed.  You may 
get an INFO or WARNING message depending on your synthesizer. 



Article: 112459
Subject: Re: Spartan 3E-Kit
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 22 Nov 2006 17:01:02 GMT
Links: << >>  << T >>  << A >>
<spartanius@arcor.de> wrote in message 
news:1164209777.649517.273910@e3g2000cwe.googlegroups.com...
>
> I am currently using the ISE 8.1 - you seem to use 8.2. Could this be
> the explanation for the errors?
>
> Anyway, I installed the newest available version now, and still have no
> success. rightclicking the *.ise opens the ISE, but I have no sources
> and have to add them manually again like before.
>
> It seems to be a challenge to get a Xilinx Environment run. (?)  Well,
> when starting with Altera`s, 2 years ago, everything worked fine the
> first run (eval board board, first project, quartus ide etc).
>
> Hm....
>
> Maybe I am a bit to lazy, or missed  something important, or I am
> simply to strong on the Altera line to switch easily.
>
> In any case I am a bit disappointed, that there are no simple and
> working examples in a -> starter kit.
>
> Anybody else working with this kit ?

I got the kit and just started modifying the existing demo.  The unused pins 
that aren't included in the top level or .ucf don't cause me any problems. 
Heck, I even expanded upon the PicoBlaze code to do my own LCD stuff.  It 
was quite a nice experience.

I have the full .ucf if/when I need to add signals in my HDL and current 
.ucf.  I used it in 8.1 and 8.2, various service packs.

I liked the kit so much I got the 1600E version, too.

- John_H 



Article: 112460
Subject: Re: board - T562.jpg
From: "rickman" <gnuarm@gmail.com>
Date: 22 Nov 2006 09:58:07 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On 22 Nov 2006 04:58:55 -0800, "rickman" <gnuarm@gmail.com> wrote:
>
> >John Larkin wrote:
> >> On 21 Nov 2006 20:14:43 -0800, "rickman" <gnuarm@gmail.com> wrote:
> >>
> >> >John Larkin wrote:
> >> >> We just solved a nasty problem with this:
> >> >>
> >> >> A d-flop: D tied high; clocked from a pin, CE from internal gating
> >> >> logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a
> >> >> delay line back into its own async clear. When the input pin rises, if
> >> >> CE permits, it makes a single clock pulse. Everything downstream is
> >> >> "synchronous" in that it's clocked from this gadget.
> >> >>
> >> >> The delay line is a chain of AND gates (with transparent latches
> >> >> enabled in the logic cells, just to add a little more delay), with
> >> >> each fed from the ff Q and also from the previous gate. This is a
> >> >> delay line with a fast discharge mechanism when its input goes low, so
> >> >> we don't have to wait for the 0 to propagate through, chasing the 1.
> >> >
> >> >How do you synchronize the input clock with the internal CE signal?  If
> >> >it is not synchronized, couldn't you get nasty splinter pulses?
> >>
> >> The gate signal is totally async to the clock. We're sort of hoping
> >> that the output of the logic block is either going to go high or not.
> >> A metastability glitch within a Spartan3 flip flop is (optimistically)
> >> narrower than the inter-cell routing can propagate. We'll have to try
> >> that and see. I could put setup and hold time requirements on the
> >> trigger gate specs, and make it the customer's problem!
> >>
> >> >How do you control the timing of the delay line?  Is the timing window
> >> >that you can work in pretty wide?
> >>
> >> The downstream logic has to work at 80 MHz max. So if we
> >> experimentally tune the BUFG output width to, say, 4 ns, we should
> >> have a pretty good margin both ways. Most silicon processes seem to be
> >> pretty stable these days.
> >>
> >> I suppose we could make the delay tunable through a register our uP
> >> could write, and we could check a test point now and then to make sure
> >> we have it right. Just a mux selecting delay-line taps would work. We
> >> only need to do this once in the product, and it's important, so this
> >> is worth some hassle. The trick is, I suppose, to only take risks when
> >> you really need to.
> >
> >I'm not sure I understand your problem, so I'll ask a few more
> >questions.  What is the speed of the clock in the design?  How often
> >does the internally clocked CE signal gate the external signal to
> >generate a clock pulse?  If the external signal will not generate a
> >clock edge on every internal clock there might be an easier way to do
> >this that does not depend on timing delays.  It can generate a clock
> >enable signal that is asserted on every other clock cycle.  But this
> >may or may not work for your application.
>
> The product is a digital delay generator. Given a customer trigger, it
> generates four pulses, each programmable for delay and width from the
> trigger. There are three clock nets on the chip:
>
> 1. Trigger, qualified by a separate gate signal, firing this one-shot.
> This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This
> drives a bunch of logic, including optional gate/countdown/burst
> logic, all of which starts...
>
> 2. A non-continuous delay-generator clock. Following the trigger, we
> start a gated 50 MHz oscillator that's used to time out 8 coarse
> delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip
> analog fine delays trim the actual edges to 10 ps resolution. This 50
> MHz clock is phase-locked to...
>
> 3. A 40 MHz clock, from a TCXO.
>
> A digital PLL thing longterm locks the customer-triggered 50 MHz clock
> to the local 40 MHz crystal oscillator but keeps the 50 MHz thing
> phase-coherent to the customer trigger, so the delay outputs don't
> jitter.
>
> Given all these clocks, and all the signals making multiple passes on
> and off the chip, we're getting output jitters in the ballpark of 50
> ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8
> ps range, but their critical paths are power-hogging PECL.
>
> Generating accurate, low-jitter delays from a random trigger, but with
> crystal-oscillator accuracy, is an interesting problem in general, and
> it's been approached a lot of ways. We think ours is nicely suited to
> implementing in an FPGA with minimal external stuff. Our main
> limitation seems to be on-chip crosstalk and maybe a bit of ground
> bounce.

I can't say I really understand what you are doing.  Obviously how you
are solving this problem is something that is too complex for a verbal
description without diagrams and detailed explanations.  But thanks for
trying.


Article: 112461
Subject: Re: 8080 FSGA model in an FPGA
From: "Grant Stockly" <grant@stockly.com>
Date: 22 Nov 2006 10:43:55 -0800
Links: << >>  << T >>  << A >>

scott moore wrote:
> http://web.cecs.pdx.edu/~harry/Relay/
>
> Why anyone would use those big relays and point to point wiring is
> beyond me.
>
> http://www.vaxman.de/my_machines/phywe/pgr/pgr.html
> http://www.electronixandmore.com/project/relaycomputer/index.html
>
> What have we learned? There are people with WAY too much time on their
> hands :-)

This one is better than those:

http://www.kilian-leonhardt.de/relaiscomputer/

He has it hooked to a typewriter for a terminal!  In some of the sound
clips you can hear it tapping out the answer!  :)  The thousand relays
make some really neat sounds!

Grant


Article: 112462
Subject: Re: 8080 FSGA model in an FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 22 Nov 2006 10:53:59 -0800
Links: << >>  << T >>  << A >>
Pretty cool!  If you read the updates on Harry Porter's machine he says
he has Linux running on it!


scott moore wrote:
> http://web.cecs.pdx.edu/~harry/Relay/
>
> Why anyone would use those big relays and point to point wiring is
> beyond me.
>
> http://www.vaxman.de/my_machines/phywe/pgr/pgr.html
> http://www.electronixandmore.com/project/relaycomputer/index.html
>
> What have we learned? There are people with WAY too much time on their
> hands :-)
>
> scott moore wrote:
> > http://zone.ni.com/devzone/cda/tut/p/id/3953
> > http://www.cotorelay.com/html/reed_relays_9300-9400_series.htm
> >
> > Using surface mount and low current, the machine would be about the
> > size of a refrigerator, and fairly slow, but workable. I doubt
> > these small reed relays would even make a noise.
> >
> > Its the "fortune" rule. Someone, somewhere makes it, and does it modern.
> > There are still buggy whips made somewhere, you just have to look.
> >
> > rickman wrote:
> >> Grant Stockly wrote:
> >
> >>>
> >>> I really want to build a computer from relays, and even priced out some
> >>> nice ones on e-bay, but I am concerned about how long it would last
> >>> before failing...
> >>
> >> One type of computer that might actually be interesting to build of
> >> relays and operate would be a time piece.  To keep the power
> >> consumption down, you might use latching relays.  The contain a
> >> permanet magnet that holds the contact in either state and a pulse from
> >> the coil is required to change the state.  Each relay is then a FF.
> >> The logic would be done by stringing relays in series or parallel to
> >> form AND and OR functions (with or without inversions).  You could also
> >> use diodes to form the logic if you want to save some space.  There are
> >> some fairly minature relays available at around $5 or less.  We are
> >> using some latching RF relays at that price.  They are about 15 x 10 mm
> >> so a clock circuit might take up a square foot depending on the
> >> density.  It would also tick every second with major noises on the
> >> minutes and hours.
> >>
> >> I am working on a relay controller circuit for an RF module and when I
> >> do the test code, it will have a few options to sound out tap dancing
> >> like music.  That should prove interesting and entertaining!
> >>


Article: 112463
Subject: Cache trouble in XPS
From: "Rune D. Jørgensen" <RUNE_dahl@hotmailREMOVE_THIS.com>
Date: 22 Nov 2006 18:57:09 GMT
Links: << >>  << T >>  << A >>
Hi

When using data cache in xilinx platform studio, to cache an external DDR 
memory(64MB) on the OPB bus and a BRAM block, I get some bad errors. The 
program runs without a hickup when the data cache is only enabled for the 
BRAM, but when enabled for the DDR memory, faulty data is read from memory.
 
The data space cached is only the DDR memory and the BRAM, so no other 
hardware should be able the mess up the cache by changing the data on the 
other side of the cache.

I have just enabled the caches with the lines:
XCache_EnableICache(0x00000001);
XCache_EnableDCache(0x80000001);

I expected this to be enough, but I have also tried to invalidate every 
data cache line before running my program, but without any luck.

What am I missing?

The system is running on a Virtex4-FX12 PowerPC.

-- 
Rune D. Jørgensen

Article: 112464
Subject: Re: ISE 8.2 & XC9500XL family
From: "Jozsef" <bit_vector@tvn.hu>
Date: 22 Nov 2006 11:01:43 -0800
Links: << >>  << T >>  << A >>
Hey, programming hardvare is same on each attempt. Using euro
connectors (JTAG connected to it for testing puuposes) . The difference
between successfull and error message is the software only....



John Adair =EDrta:
> Your symptoms suggest a JTAG chain problem and could be reflections on
> the chain, poor power supply to JTAG head, poor head connections,
> pickup of noise on JTAG. If you are using the flying lead set normally
> attached to Cable III head do check the connectors of lead set. These
> have a habit breaking eventually. Also check if the TDO line out of the
> XC95144XL needs a pullup to operate correctly and it's value. Some
> parts do and some don't.
>
> John Adair
> Enterpoint Ltd.
>
> Jozsef wrote:
> > Hello,
> >
> >  as many people over this world, I have a problem. The problem is the
> > connection beetween a CPLD and the WEBPACK ISE 8.2.03 software.
> > Simptoms like very static: I have an Parallel Cable III, the ISE
> > software, and a XC9500XL family CPLD. The Impact cannot recognise the
> > CPLD, for example a simple XC95144XL showed five unknown device in the
> > JTAG chain on automatic JTAG chain initialize. I' has been tried to add
> > the device manually, but there is not accepted as a result, because
> > Impact answers unknown device ID. I'm told each family because tried
> > with xc9536XL, simptoms are same.
> > The cable is OK, I using it to program other devices (for example,
> > XC3S400) on everyday.
> > On software side, tried an older software (Xilinx Foundation 4) to
> > program these devices, that programs all without problems.
> >=20
> >  The question is what is the problem with ISE 8.2.03 ???


Article: 112465
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Wed, 22 Nov 2006 19:22:31 GMT
Links: << >>  << T >>  << A >>
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote:
>> Rob, my best FPGA guy, has given up on using the Xilinx 8.2/sp3 IDE
>> software... it's way too flakey. But he says the underlying chunks
>> work fine from the command line, so he put together a "make" thing to
>> process the chip we're working on. So it looks like the core
>> fpga-crunching software was coded by people who know what they're
>> doing, and the IDE wrapper (which runs in 90 megabytes of ram!) was
>> coded by Windows programmers.
> 
> Seems the GUI-mafia just love RAM.. :)
> 
That's one of the laws of software:

All programs expand to consume all available resources

I remember implementing a RAM test in 34 bytes, and a 16x16 integer 
multiply in < 50 bytes.

Cheers

PeteS

Article: 112466
Subject: Re: Protecting netlist for Xilinx
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 22 Nov 2006 11:33:59 -0800
Links: << >>  << T >>  << A >>
Sylvain Munaut <SomeOne@SomeDomain.com> wrote:

> I'm working for a company that sell FPGA IP in netlist form.
> I'd like to protect theses IP as much as I can, to try to make
> it as hard as possible to RE them. I know I can't possibly
> fully protect them, but that doesn't mean it doesn't worth trying.
> 
> I've already used the "secure netlist" option of the Xilinx tools,
> but it's not that secure. Also, the net names stays the same.
> So I'm looking at an obfuscating tool that would rename
> all net/instances for me. 

Brands X and A do this for the cores that
they resell, so it can be done, but it
might also cut your profit margin to zero.
Consider distributing your stuff via a vendor IP program.

> And also other methods you might know ?

The only one I know of is dealing with people
you trust and signing legally binding contracts.
At the high end, customers are willing to pay
for source code and support.

  -- Mike Treseler

Article: 112467
Subject: Re: 8080 FSGA model in an FPGA
From: "Grant Stockly" <grant@stockly.com>
Date: 22 Nov 2006 11:53:10 -0800
Links: << >>  << T >>  << A >>

rickman wrote:
> Pretty cool!  If you read the updates on Harry Porter's machine he says
> he has Linux running on it!

I don't think any software ever "runs" on a relay computer...  ; )


Article: 112468
Subject: Re: I2C "READ" Setup/Hold Requirement
From: "markus" <markus_1401@yahoo.com>
Date: 22 Nov 2006 11:58:27 -0800
Links: << >>  << T >>  << A >>
Thanks.

Your post definitely explains why I have problems (or no problems) with
certain slaves.

Have a Great Thanksgiving!


Daniel S. wrote:
> Hi,
>
> I have been having fun with I2C for a while. If you read the I2C specs,
> you will see that the same delays come up everywhere for any given bus
> speed.
>
> For 400kbps, this magic number is 600ns: SCL and SDA pulses must be
> 600ns wide minimum, a master should leave the bus idle for 600ns between
> transactions, SDA-to-SCL edges for start/stop should be at least 600ns
> apart, etc.
>
> Since the condition between your #2 and #3 should be a 'restart', there
> should usually not be any extra delays needed there, other than the
> usual 600ns SDA-to-SCL for start/stop conditions. Then again, many I2C
> devices have quirks that must be dealt with on a case-by-case basis.
>
> The opencores I2C master is somewhat odd: it seems that its designer
> forgot to provide some means of generating interrupts before the master
> outputs the ACK bit when reading a slave. Without this, the host has to
> divine whether or not the next byte received will be ACK'd. With that
> interrupt (and freezing SCL), the host would be able to make this (ACK)
> decision after receiving the byte.
>
> markus wrote:
> > Hello
> >
> > For the I2C read, the step by step, the algorithm is:
> >
> > 1). write slave address+write bit
> > 2). write register address
> > 3). write slave addres+read bit
> > 4). read
> >
> > After the end of step 2, and before step 3, you need to set the STA to
> > indicate the real read. Note that STA is indicated by transition of
> > HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there
> > is minimum wait time between step 2 and beginning of step 3?
> >
> > Note that my design uses OpenCores' I2C (if it matters). Thanks.
> > 
> > Happy Turkey Day,
> > -M
> >


Article: 112469
Subject: Re: Protecting netlist for Xilinx
From: PeteS <peter.smith8380@ntlworld.com>
Date: Wed, 22 Nov 2006 20:12:27 GMT
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Sylvain Munaut <SomeOne@SomeDomain.com> wrote:
> 
>> I'm working for a company that sell FPGA IP in netlist form.
>> I'd like to protect theses IP as much as I can, to try to make
>> it as hard as possible to RE them. I know I can't possibly
>> fully protect them, but that doesn't mean it doesn't worth trying.
>>
>> I've already used the "secure netlist" option of the Xilinx tools,
>> but it's not that secure. Also, the net names stays the same.
>> So I'm looking at an obfuscating tool that would rename
>> all net/instances for me. 
> 
> Brands X and A do this for the cores that
> they resell, so it can be done, but it
> might also cut your profit margin to zero.
> Consider distributing your stuff via a vendor IP program.
> 
>> And also other methods you might know ?
> 
> The only one I know of is dealing with people
> you trust and signing legally binding contracts.
> At the high end, customers are willing to pay
> for source code and support.
> 
>   -- Mike Treseler

When it comes to these things, it ultimately comes down to trusting 
customers and partners (backed up by a suitable contract, of course).

If someone is determined to crack the IP, they will very probably do so. 
We both pay per unit for some things and get paid per unit for others. 
We don't do business any more with certain companies, shown in one 
particular case where they claimed they only sold 'x' units, but we 
found out (by coincidentally talking to their biggest customer) that
they had sold many hundreds 'x'.

Some might say the pricing was too high, but in that case they were free 
to ask for renegotiation of the contract or simply stop using the 
provided functionality - if they stopped, we got nothing (we were paid 
based on sold units), so we had plenty of motivation to look at it 
should that happen.

No - Mike is right - do business with those you can trust. I know that's 
not necessarily easy for some companies and it can be quite a conundrum.

Cheers

PeteS

Article: 112470
Subject: Re: board - T562.jpg
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Wed, 22 Nov 2006 20:28:11 GMT
Links: << >>  << T >>  << A >>

"PeteS" <peter.smith8380@ntlworld.com> wrote in message 
news:Xr19h.59126$r4.34900@newsfe3-gui.ntli.net...

> That's one of the laws of software:
>
> All programs expand to consume all available resources
>
> I remember implementing a RAM test in 34 bytes, and a 16x16 integer 
> multiply in < 50 bytes.

I once wrote an Eratosthenes' prime number sieve using the video display as 
an array memory (on a 4K machine).








Article: 112471
Subject: Re: board - T562.jpg
From: John Fields <jfields@austininstruments.com>
Date: Wed, 22 Nov 2006 15:03:54 -0600
Links: << >>  << T >>  << A >>
On Wed, 22 Nov 2006 20:28:11 GMT, "Homer J Simpson"
<nobody@nowhere.com> wrote:

>
>"PeteS" <peter.smith8380@ntlworld.com> wrote in message 
>news:Xr19h.59126$r4.34900@newsfe3-gui.ntli.net...
>
>> That's one of the laws of software:
>>
>> All programs expand to consume all available resources
>>
>> I remember implementing a RAM test in 34 bytes, and a 16x16 integer 
>> multiply in < 50 bytes.
>
>I once wrote an Eratosthenes' prime number sieve using the video display as 
>an array memory (on a 4K machine).

---
How high did it go?  to 9?


-- 
JF

Article: 112472
Subject: Division of a (rather large) Gate level Combinational Design
From: olson_ord@yahoo.it
Date: 22 Nov 2006 13:14:49 -0800
Links: << >>  << T >>  << A >>
Hi,
	This is the second time I am posting to this group within a week, but
I think that this necessitates another thread. (Through google groups
my original thread can be accessed at
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/6f620f38f06a19df?hl=en)

	My problem is that I am trying to synthesize gate level combinational
circuits that have a large number of signals. (I actually did not
realize how large it was till Thomas and Andreas explained it to me in
the previous thread.) My circuit probably uses around 40 K gates, but a
lot more signals.

	From the discussion in my previous thread, I realized that the
synthesis tools (I use XST) have/has problems with
(1)	large number of signals
(2)	large combinational paths

I don't really mind the synthesis time - rather I am concerned that I
run out of memory. (I hit 4 GB - and I don't have the 64 bit version.)

	I would also like to mention that as far as the number of gates is
concerned, I am sure that my design would fit onto one FPGA, with a
utilization of less than 50%. (Using the xc2v6000-4.)

	Does anyone have an idea how I can get this to synthesize? Partial
Synthesis (i.e. synthesis of parts of my design separately) was
suggested to me in my previous post, but I could not figure out how to
do this in XST. (I can dump out the NGC files for different parts of my
design - but how do I combine them?)

	If long combinational paths are an issue, is there a way to break up a
long combinational path (i.e. add registers or latches etc.). I thought
about latches - but then deciding where to insert the latches is a big
question. (I don't mind compromising on timing if this is a factor of
2, 3 or even 10, but I don't want this running into a factor of 100's
or 1000's.)

Thanks to all those who may have some ideas.
O.O.


Article: 112473
Subject: Re: EDK 8.2 Block RAM error
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 22 Nov 2006 17:04:25 -0500
Links: << >>  << T >>  << A >>
"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1164200166.358021.84400@m73g2000cwd.googlegroups.com...
>
> BUG::: EDK 8.2  generates BMMs incompatible with ISE 8.2
> when BRAM blocks are consecutive.
> if there is gap in address space then it all works.
>
> there is a workaround to manually fix the generated BMM files

So they broke it in 8.2!!!! Are you talking about the AR 24296 for the fix? 
This is as ugly as it can only get :( I can't beleive this....

/Mikhail









Article: 112474
Subject: Re: Protecting netlist for Xilinx
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Thu, 23 Nov 2006 00:08:25 +0100
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Sylvain,
> 
> Protecting IP is one issue.  Providing a means for IP developers to be
> paid for the use of their IP is another problem (and different).  Using
> multiple IP from multiple vendors, and all getting paid is yet a third
> problem.
> 
> As you point out, today there are few good ways (really none) to do any
> of the above.

Yes, preventing someone to loading the .bit else where is not really
easy ;)
 
> There is AES256 encryption and decryption in V4 and V5 which provides a
> FIPS-140 compliant solution for the protection of the IP.

Yes, but that's from the guy who provide the .bit perspective. To protect
from a user of the final product.

Here I'm more talking about the guys who receive the .ngc, prevent them
to look inside it too easily. (I know a motivated attacker will succeed
at looking inside but if it could take him more than 15 min that would be
nice ...)

Obfuscating the net name would be a good start, since without names and
hierarchy, figuring out how a 10k slices IP work should take him a while.

> Obfuscation (keeping a secret by keeping secrets) should never be
> considered secure, as paying someone in the parking lot is all it takes
> to crack it.  Keeping your algorithm a secret is equally dumb, as most
> "clever" and "secret" functions are easily cracked (since they have had
> no serious peer cypto review).

The point here is not a crypto algorithm at all. Every body knows how
to do it (video compression standard). But everybody doesn't know how
to do it very quickly and efficiently in a FPGA ...



Sylvain



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