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 114750

Article: 114750
Subject: Re: FPGA damage from bad bitstream
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 23 Jan 2007 14:11:12 -0800
Links: << >>  << T >>  << A >>
jbnote,

See answers in line below,

Austin

-snip

> Sorry for not reading the docs, is encryption only used on frame data
> in the bitstream?

Encryption is used for the "bitstream", but not for configuration
commands.  CRC32 check is a command.  Startup is a command.

> - If encryption is for the full bitstream, then there's not even one
> chance that the random garbage will make sense to the bitstream
> microcontroller, so you're safe.

It is unlikely that an attacker can change what they want to cause a
specific result, as CBC will corrupt the following block(s) as well.  If
they already knew the design, then they don't need to un-encrypt the
bitstream, do they?  If they just wish to break it, use a hammer.  If
they wish to insert their own program, NOTHING prevents that (we accept
all bitstreams, a true equal opportunity employer).

> - If encryption is limited to the data stream, then on the virtex2,
> it's very easy to disable CRC checking and load random garbage for
> which I'd guess frying configurations on long lines would not be
> uncommon (let's do the math !).

Yes, you can just skip the CRC check, and startup anyway.  Virtex 2 and
later devices are unlikely to "burn up" but they may be some contention.

> On virtex4 and virtex5, I'd expect that each frame's Hamming SECDED
> code is checked by the loading state machine and encrypted, so random
> garbage would be rejected ? Or does Hamming Code sits there for nothing
> at load-time ?

Oh, that would be nice, but no, the bits do nothing of the sort.  If you
wished, you could use those bits for a watermark, or some other reason.
 Just because we call them the frame syndrome bits doesn't really make
them special (until you want to use the FRAME_ECC feature).

Article: 114751
Subject: Re: Xilinx ISE 8.2
From: doug <doug@doug>
Date: Tue, 23 Jan 2007 14:23:12 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Brian,
> 
> http://tinyurl.com/367qnf
> 
> Details the technical answer on this subject.
> 
> Austin
I am a long time lurker on this newgroup and have learned
a lot from it.  I very much appreciate the presence of Austin
and Peter and the help that they provide.

However, what got me to post this is that the url above just
adds insult to injury regarding ise.  I am a long time user of
Xilinx software starting in about 1991.  For most of that period
the software has been terrible.  The XACT software required you
to reboot after every run, either voluntarily or it would do it
for you.  By the time of the Foundation series, the software was
getting reasonable.  I even bought a copy for my personal use.

ISE has been an experience.  By version 6.3 it was reasonably
good.  It did what I wanted and did not cause too much trouble.
Version 7 was a huge step backwards.  Project navigator got user
surly and very slow.  Whoever did the design never used it for
anything.  Version 8 reached a new low.  The stupid design to
change the project files, later partly removed, made for lots of
headaches.

Fortunately I was spared a lot of the headaches of version 8 since
it would not compile my design.  For a variety of reasons, mostly
historical, a large part of my design is schematics.  There is a
major memory leak in the schvhdl module.  It leaks at about 1mb
per second of cpu time.  Version 7 would complete the xst portion
in about five minutes with a peak memory useage of around 120mb.
Version 8 took an hour or so of time and then crashed at just over
2gb of useage.  There was no way to compile the project and this
was confirmed by Xilinx tech support.  The only "workaround" was
to tell it to compile to verilog instead of vhdl since that memory
leak was not as bad.  Unfortunately this was not an option since
the peak memory useage was just about the 2gb point where the vhdl
conversion failed and blew up the program.

The memory leak was a problem in version 8.1
It was not fixed in 8.1 sp1
It was not fixed in 8.1 sp2
It was not fixed in 8.1 sp3
It was not fixed in 8.2
It was not fixed in 8.2 sp1
It was not fixed in 8.2 sp2
It was not fixed in 8.2 sp3
It was not fixed in 9.1
It was not fixed in 9.1 sp1

So the latest and greatest version 9.1 and its service pack have done
nothing to help make a relatively small design work.  If they are not
going to improve things, why break stuff that was working ok?

Memory leaks come from sloppy programmers.  Not fixing memory leaks
comes from lazy or incompetent programmers.  It is clear that the
programmers did not test their code.  They seem to think that "testing"
means looking to see if it blows up in the first ten seconds.  This is
not some exotic hard to reproduce bug.  Take an 2 input and gate and
put iopins on it.  The memory leak is about 3mb as I recall.  This is
not subtle or hard to find.  They did not even look.  They have not
been looking since it was pointed out and there is no reason to believe
that they have any intention of looking for the leaks.

At one point I sent in a list of fourteen bugs in ise for version 7.
They are all still there plus lots of new ones I have seen in the
little I have been able to use the newer versions.

The conclusion of this is that pointing to a url which just points
out that the programmers did not bother to test their code does
not help the users.  What is needed is to get programmers who know
what they are doing and FIX the problems.

Xilinx support recommended vhdl as it is more portable.  That is true
and will make it easier to take designs to other manufacturers.



Article: 114752
Subject: Re: FPGA power supply design
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 23 Jan 2007 22:35:54 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Kunil,
> 
> http://www.xilinx.com/products/design_resources/power_central/
> 
> Use the "XPower Estimator" tool to find the intended power requirements.
> 
> Then scroll down to "Partners"
> 
> and pick your favorite vendor.
> 
> Follow the links.
> 
> Really quite simple.  Not sure why others are making such a big deal out
> of this.  It is really a trivial issue.  The power requirements which
> require very low noise, are the MGT analog supplies, and there is a huge
> user's guide to help you there (as well as manufacturer part numbers,
> and sample schematics).
> 
> Every one of these vendors has met with Xilinx, and had their products
> reviewed.  These vendors are used on our own boards.
> 
> The only really difficult part is estimating the power you will use,
> because we have no control over what you program into our parts.  All we
> can do is provide the tools to make estimates (which are based off the
> quality of information you give them).  So, if you put garbage in, you
> get garbage out.
> 
> Austin

Now I'm home....

Hmmm - it's not a big deal if a design is strictly specified and 
simulated long before it's laid out. That may be possible (indeed, is, I 
am sure) within Xilinx (and all the other vendors), but out here in 
productland the PCB designer is left with, at best, a [hopefully 
educated] guess simply because the design is nowhere near complete 
before the board goes to layout. I prefer at least a SWAG to a mere WAG.

By that time, the power has to be specified of course. That's why I 
overspecify it (I have a specific bag of tricks I use for Xilinx FPGAs 
just as I have them for other vendors) based on core size, IOs, IO 
speeds I expect etc., but I don't normally get power estimates from the 
FPGA designer (when it isn't me) until long past the time it would be 
useful for the original design stage.

Then there's feature creep. What happens if I specify the core power 
minimally (from a design) to save money and then I suddenly find we're 
going to drop a high speed arbitrator into the device ?(your choice of a 
large piece of functionality here).

I'm sure I am not the only one that has to deal with that, but it is the 
reality of product design, whether we like it or not.

My answer is to have power designs that cover the worst case for all 
three of VIO, Vcore and Vaux.

Cheers

PeteS

Article: 114753
Subject: Re: FPGA power supply design
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 23 Jan 2007 22:44:36 GMT
Links: << >>  << T >>  << A >>
PeteS wrote:
> Austin Lesea wrote:
>> Kunil,
>>
>> http://www.xilinx.com/products/design_resources/power_central/
>>
>> Use the "XPower Estimator" tool to find the intended power requirements.
>>
>> Then scroll down to "Partners"
>>
>> and pick your favorite vendor.
>>
>> Follow the links.
>>
>> Really quite simple.  Not sure why others are making such a big deal out
>> of this.  It is really a trivial issue.  The power requirements which
>> require very low noise, are the MGT analog supplies, and there is a huge
>> user's guide to help you there (as well as manufacturer part numbers,
>> and sample schematics).
>>
>> Every one of these vendors has met with Xilinx, and had their products
>> reviewed.  These vendors are used on our own boards.
>>
>> The only really difficult part is estimating the power you will use,
>> because we have no control over what you program into our parts.  All we
>> can do is provide the tools to make estimates (which are based off the
>> quality of information you give them).  So, if you put garbage in, you
>> get garbage out.
>>
>> Austin
> 
> Now I'm home....
> 
> Hmmm - it's not a big deal if a design is strictly specified and 
> simulated long before it's laid out. That may be possible (indeed, is, I 
> am sure) within Xilinx (and all the other vendors), but out here in 
> productland the PCB designer is left with, at best, a [hopefully 
> educated] guess simply because the design is nowhere near complete 
> before the board goes to layout. I prefer at least a SWAG to a mere WAG.
> 
> By that time, the power has to be specified of course. That's why I 
> overspecify it (I have a specific bag of tricks I use for Xilinx FPGAs 
> just as I have them for other vendors) based on core size, IOs, IO 
> speeds I expect etc., but I don't normally get power estimates from the 
> FPGA designer (when it isn't me) until long past the time it would be 
> useful for the original design stage.
> 
> Then there's feature creep. What happens if I specify the core power 
> minimally (from a design) to save money and then I suddenly find we're 
> going to drop a high speed arbitrator into the device ?(your choice of a 
> large piece of functionality here).
> 
> I'm sure I am not the only one that has to deal with that, but it is the 
> reality of product design, whether we like it or not.
> 
> My answer is to have power designs that cover the worst case for all 
> three of VIO, Vcore and Vaux.
> 
> Cheers
> 
> PeteS

I would hasten to add that the power estimator is a great tool, even 
after the fact, to help with overall board power calculations (where 
thermal issues might be handled after layout).

Cheers

PeteS

Article: 114754
Subject: Re: Different Modelsim versions disagree in same backannotation!
From: Paul Jansen <pj30145@yahoo.com>
Date: Tue, 23 Jan 2007 23:03:51 +0000
Links: << >>  << T >>  << A >>
Sorry, I only check in here when I get really bored... :)

On 20 Jan 2007 10:43:16 -0800, "spectrallypure" <jorgelagos@gmail.com>
wrote:

>Thanks so much for your reply, Paul. Here I add some information:
>
>> #1 - Why is one signal rising at 10264ns, and the other at 10263ns?
>As I told before, i just can't figure out why there are differences in
>the the timming of the signals. What puzzles me the most is that even
>the signal SHIFTWR (which is generated by the testbench and has nothing
>to do with the synthesized netlist whatsoever) changes its timming,
>presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly
>this is unexpected behavior. I have no clue of what could be the reason
>nor how to trace it back...

Cut down your test bench, don't instantiate your device, see if you
can confirm that SHIFTWR timing changes even without the synthesised
netlist. I doubt it, but you will need to fix this first if you're
right. If this really *is* the case, then there's almost certainly an
error in your testbench, which will probably be either a race
condition or a timing resolution problem. If it's not obvious (it
should be), manually check the timing on whatever logic drives
SHIFTWR. At some point, you should find that the numbers start
diverging between 5.8 and 6.2. This will be very tedious, but you
should manage it within a few hours.

You're in trouble if you don't understand race conditions. Google
comp.lang.verilog; you'll find a huge number of posts on it.

If this is a school project, as I suspect it is, then you should
probably give up. If it's a real project and you actually need a fix,
then I'm afraid that you're probably going to have to pay someone to
sort it out. Running PrimeTime and back-annotated ASIC timing sims is
not a job for beginners. Reply if you're interested, and I'll send you
my real email address.

>In 5.8b I get a lot (nearly 50,000) of the following warnings:
>
># ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
>here->): Failed to find matching specify timing constraint.

Rule #1 when you get an error message you don't understand: Google it.
Ther are some exact matches on your error message, which suggest that
you might not have recompiled your simulation libraries when changing
ModelSim versions. For ModelSim, you always need to recompile
libraries when changing major version numbers.

/PJ

Article: 114755
Subject: Re: FPGA damage from bad bitstream
From: Ben Jackson <ben@ben.com>
Date: Tue, 23 Jan 2007 17:12:24 -0600
Links: << >>  << T >>  << A >>
On 2007-01-23, stephen.craven@gmail.com <stephen.craven@gmail.com> wrote:
> Does anyone know if it is possible to permanently harm a Xilinx FPGA
> internally through a bad (accidental or malicious) bitstream?

One totally unobvious one is:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22471

Running without an MGT hooked up for 400 hours might cause it to permanently
fail!

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 114756
Subject: Re: "Divide" a video line in two stripe
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 23 Jan 2007 15:14:09 -0800
Links: << >>  << T >>  << A >>


On Jan 22, 12:33 am, "Sylvain Munaut <Some...@SomeDomain.com>"
<246...@gmail.com> wrote:
> Here's my problem :
>
> A have a video module (that I can't really change), that outputs a
> 3840x2400 image, by outputing two consecutive pixels at once (like
> dual-link DVI). The problem is that the screen to display that doesn't
> want dual-link DVI, it wants two independant DVI stream, one for the
> left part of the screen and another for the right part of the screen.
> (two "stripes" of 1920x2400).
> I'm trying to come up with a solution to "transform" one into another,
> without using a frame buffer nor storing more than 1 line of video.
> (At 3840, in color, that already is 6 Xilinx BRAMs and I'm a little
> short of those ...).
> According to my calculations, It should even be possible to only store
> half a line, but I prefer to have a 1 line delay than half a line
> delay.
> My problem is that I can't find how to do it ... Storing in BRAM has
> proven to be an addressing nightmare

Nobody has provided what you really want here yet.
I sympathize with the need to conserve BRAM in video applications.
Maybe we can turn your nightmare into a sweet dream.

> to store and reread simultaneously
> without overwriting data I haven't re-read yet ... (since I don't read
> in the same order that I write).
>
> Does anyone has done something similar or has a genius idea ? Because
> I'm missing something here, that should be simple and I just don't see
> it ...
>
> Sylvain

Sylvain,
  The approach to solving your addressing dilemma is to start small.
Look at a line that is only 12 pixels long. On your first pass you will
write to these locations:
| first half line        |  second half line        |
   0   1   2   3   4   5   6   7   8   9  10  11
On your next line, you want to Read before Write these locations:
   0   6   1   7   2   8   3   9   4  10   5  11
Continuing this pattern gives:
   0   3   6   9   1   4   7  10   2   5   8  11
   0   7   3  10   6   2   9   5   1   8   4  11
   0   9   7   5   3   1  10   8   6   4   2  11
   0  10   9   8   7   6   5   4   3   2   1  11
   0   5  10   4   9   3   8   2   7   1   6  11
   0   8   5   2  10   7   4   1   9   6   3  11
   0   4   8   1   5   9   2   6  10   3   7  11
   0   2   4   6   8  10   1   3   5   7   9  11
   0   1   2   3   4   5   6   7   8   9  10  11
and voila, you're back where you started.

Now how do you produce these numbers?
Let the magic of modular arithmetic help you.
Below is a perl script that generates the sequences you need, and shows
everything you need to do. It takes one accumulator and one counter, an
addition, a comparison, and optional subtraction. Limit may be
programmable since you want to handle arbitrary line lengths right?.
You have not mentioned what clock rate you have, but if you translate
this into VHDL, you may even be able to get the addition, comparison,
and optional subtraction into a single cycle. If not, then you can
double the width of the BRAM inputs/outputs using external registers,
demuxes/muxes until you have enough time to do the requisite modular
addition.

I expect this is what you wanted,
HTH
Just John

Herewith, the perl script...
#!/bin/perl
use strict;
my $Limit = 11; # One less than line length
my $Middle = $Limit >> 1; # Routing operation
my $Loop = $Limit + 1;
my $NewIncr = 1;
while ( $Loop-- ) { # Loop over lines
#  printf "Loop %2d:", $Loop;
  my $Incr = $NewIncr;
  my $Addr = 0;
  my $C = 0;
  while ( $C != $Limit ) { # Loop over pixels in lines
    printf "  %2d", $Addr;
    $Addr += $Incr;
    $Addr -= $Limit  if ( $Addr > $Limit );
    $NewIncr = $Addr if ( $C == $Middle );
    $C++;
    }
  printf "  %2d\n", $Limit;
  }


Article: 114757
Subject: Re: R: iMPACT dont shows erase write options with fpga
From: Ben Jackson <ben@ben.com>
Date: Tue, 23 Jan 2007 17:23:34 -0600
Links: << >>  << T >>  << A >>
On 2007-01-23, blisca <> wrote:
> maybe i'm too drunk after soldered tiny wires with cheap lens on the bottom
> of this BGA
>
> so i did this almost senseless question

Drunk is the right state to use iMPACT.  For example, if you go back and
forth between writing .bit's into FPGAs and .mcs's into Xilinx config
proms, you will want to stab someone each time you forget to turn ON
erase/verify/use-internal-config-clock for the PROM because iMPACT
mysteriously forgot those settings... AGAIN

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 114758
Subject: Re: "Divide" a video line in two stripe
From: "Peter Alfke" <peter@xilinx.com>
Date: 23 Jan 2007 15:34:03 -0800
Links: << >>  << T >>  << A >>
Rob, since you mentioned XILINX BRAM architecture:
Yes, each BlockRAM has two ports that are compltely independent.
On each port, during a write operation, you can read the previous
content of the memory word that you are just now writing into.
This is a configuration option: either read the old content, or the new
content, or leave the output word untouched.
Peter Alfke, Xilinx Applications

On Jan 22, 7:20 pm, "Rob" <robns...@frontiernet.net> wrote:
> Sylvain
>
> I'm not familiar with Xilinx's memory architecture; but if their memory blocks have the option of being run in dual-port mode it could make this problem much easier to deal with.  
>
> In the past I've taken advantage of other mfg's mixed-port read-during-write mode.  This mode is used when a RAM has one port reading and the other port writing to the same address location with the same clock. The memory block outputs the old data at the specified address when there is a simultaneous read during write to the same port. You then could set up two blocks (one for each half of the image) a line deep.
>
> First fill the memory blocks with line 1
>
> fill block a
>
> *reset wraddr_a back to addr 0 and wait for block b to fill
>
> fill block b
>
> reset wraddr_b back to addr 0
>
> now you read through the two blocks simultaneously while writing to the same address for block_a
>
> reset wraddr_b back to addr 0
>
> repeat *
>
> You'll have two pointers for each memory block, one read and one write pointer.
>
> I haven't done any work with DVI so I may be missing something specific to that interface.  If so, my apologies.
>
> Take care,
>
> Rob
>
> "Sylvain Munaut <Some...@SomeDomain.com>" <246...@gmail.com> wrote in messagenews:1169454808.249472.167130@a75g2000cwd.googlegroups.com...
>
> > Here's my problem :
>
> > A have a video module (that I can't really change), that outputs a
> > 3840x2400 image, by outputing two consecutive pixels at once (like
> > dual-link DVI). The problem is that the screen to display that doesn't
> > want dual-link DVI, it wants two independant DVI stream, one for the
> > left part of the screen and another for the right part of the screen.
> > (two "stripes" of 1920x2400).
>
> > I'm trying to come up with a solution to "transform" one into another,
> > without using a frame buffer nor storing more than 1 line of video.
> > (At 3840, in color, that already is 6 Xilinx BRAMs and I'm a little
> > short of those ...).
>
> > According to my calculations, It should even be possible to only store
> > half a line, but I prefer to have a 1 line delay than half a line
> > delay.
> > My problem is that I can't find how to do it ... Storing in BRAM has
> > proven to be an addressing nightmare to store and reread simultaneously
> > without overwriting data I haven't re-read yet ... (since I don't read
> > in the same order that I write).
>
> > Does anyone has done something similar or has a genius idea ? Because
> > I'm missing something here, that should be simple and I just don't see
> > it ...
> 
> > Sylvain


Article: 114759
Subject: Re: Xilinx ISE 8.2
From: "bgshea" <bgshea@gmail.com>
Date: 23 Jan 2007 15:43:17 -0800
Links: << >>  << T >>  << A >>
I don't doubt what you are saying about the memory leaks. However, i
have to take in to consideration JAVA, which has no real memory
management, and by this i mean you cannot malloc and free memory,
rather it relys on the fact that you use the new and delete operators.
But even then if it suspects that a block of memory is going to be used
it will not let it go.

As much as i love Firefox it suffers from the same memory leak issues.
About once every 3 or 4 days i have to close out all browsers and free
up about 600MB of memory.

I also cannot blame Xilinx for using JAVA, as it works on my Linux
x86_64 AMD machine (at least i could start the project navagator) with
very little fuss.

I also agree version 8 was a step backward, it added some new icons,
design partitions and a whole bunch of nothing usefull. I have never
had the pleasure of using 6.3 in depth, when i got in to CPLD/FPGAs,
(early 2000) i used CUPL on an Altera Device, and needless to say it
worked very well as a glue logic chip. I think i used Xilinx 6.3 for
about one or 2 months before 7.1 appeared and quiclky switched.

Right now, i would like to find a good method of using the Xilinx
Tools, since I'm using their FPGAs, to conduct long term hardware
validations without restarting all the tools about once every 10
builds.  Yes, i know that i am probably not doing this 100% right and
more simulation could lead to less building but, if i had all the time
in the world to complete my projects i would simulate every last aspect
including my drive to work to ensure it would not effect my coding
style that day, you get what i mean.

So, I ask Martin, as he posted a method of using build scripts, if you
could even if in part, post some of what you use, that might benefit
the community here.  I would certainly build on those scripts and post
them back.

I still have not received a difinitive answer to a key question i had
posted, if anyone knows, can you provide some light on the subject.

Does Xilinx use it's own canned JRE or does it use the installed JRE?

I have just downloaded and installed Java SE Runtime Environment 6 from
Sun, maybe it will help maybe not.

--Brian

On Jan 23, 2:57 pm, "jbnote" <jbn...@gmail.com> wrote:
> > Memory leaks come from sloppy programmers.  Not fixing memory leaks
> > comes from lazy or incompetent programmers.Even incompetent programmers can manage this. The use of valgrind
> [http://www.valgrind.org] will pinpoint memory leaks right to the line
> where the allocation was made. It runs on unmodified software. This
> would be, oh, one hour work maximum if you have the source.
> 
> JB


Article: 114760
Subject: Re: FPGA power supply design
From: "kunil" <kunilkuda@gmail.com>
Date: 23 Jan 2007 16:04:58 -0800
Links: << >>  << T >>  << A >>

Dear all,

Thank you for all of your suggestions.

Regards,
-daniel


Article: 114761
Subject: Re: Good hardware design code re-use strategies, reference book
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 24 Jan 2007 00:12:48 -0000
Links: << >>  << T >>  << A >>
Google Subversion. And if you use Windows, Google Tortoise.
HTH, Syms.
p.s. This chap recommends it on his blog.
http://www.cambriandesign.com/






Article: 114762
Subject: Re: "Divide" a video line in two stripe
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 23 Jan 2007 18:30:41 -0800
Links: << >>  << T >>  << A >>
Sylvain,
   Speed tip for modular address calculation:
On Jan 23, 3:14 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote:
> On Jan 22, 12:33 am, "Sylvain Munaut <Some...@SomeDomain.com>"
>   The approach to solving your addressing dilemma is to start small.

_An_ approach...

> Look at a line that is only 12 pixels long. On your first pass you will
> write to these locations:
> | first half line        |  second half line        |
>    0   1   2   3   4   5   6   7   8   9  10  11
> On your next line, you want to Read before Write these locations:
>    0   6   1   7   2   8   3   9   4  10   5  11
> Continuing this pattern gives:
>    0   3   6   9   1   4   7  10   2   5   8  11
>    0   7   3  10   6   2   9   5   1   8   4  11
>    0   9   7   5   3   1  10   8   6   4   2  11
>    0  10   9   8   7   6   5   4   3   2   1  11
>    0   5  10   4   9   3   8   2   7   1   6  11
>    0   8   5   2  10   7   4   1   9   6   3  11
>    0   4   8   1   5   9   2   6  10   3   7  11
>    0   2   4   6   8  10   1   3   5   7   9  11
>    0   1   2   3   4   5   6   7   8   9  10  11
> and voila, you're back where you started.
>
> Let the magic of modular arithmetic help you.
> Below is a perl script that generates the sequences you need, and shows
> everything you need to do. It takes one accumulator and one counter, an
> addition, a comparison, and optional subtraction. Limit may be
> programmable since you want to handle arbitrary line lengths right?.
> You have not mentioned what clock rate you have, but if you translate
> this into VHDL, you may even be able to get the addition, comparison,
> and optional subtraction into a single cycle. If not, then you can
> double the width of the BRAM inputs/outputs using external registers,
> demuxes/muxes until you have enough time to do the requisite modular
> addition.
I wasn't thinking all the way through in the last two sentences above.
I expressed the modular increment as:
    $Addr += $Incr;
    $Addr -= $Limit  if ( $Addr > $Limit );
Since this is probably very fast stuff (being Hi-Res video), and done
in H/W, you can take a different approach.
Rather than do the addition, then the comparison, then the optional
subtraction, do two versions of the addition in parallel, and a
modified comparison, using that to select between the two results.
( Let A = Addr, I1 = Incr, I2 = Incr - Limit )
I2 is computed sometime after NewIncr is set in the previous line, and
before the current line starts.
The two additions are:
A1 = A + I;
A2 = A + I2;
The original comparison I posted was essentially:
if ( ( A + I ) > L )
This can be reworked by letting C = L - I
Since L and I are fixed for the line duration, C can be computed once
before the line starts.
Using C, the comparison becomes

if ( A > C )
  A <= A2
else
  A <= A1

The whole circuit operates almost as fast as a simple counter followed
by a mux.
You can extend the concept to operate on both ports of a DP_BRAM, so
that you can retrieve
both first half line pixels and second half line pixels simultaneously.
(Left as an exercise).

HTH
Just John


Article: 114763
Subject: Re: FPGA damage from bad bitstream
From: Alex Colvin <alexc@TheWorld.com>
Date: Wed, 24 Jan 2007 04:13:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
>Does anyone know if it is possible to permanently harm a Xilinx FPGA
>internally through a bad (accidental or malicious) bitstream?

about 10 years ago i had a loaded one from a bad eeprom. blew little holes 
in the package.

-- 
	mac the naf

Article: 114764
Subject: Xilinx Constraints Editor doesn't work anymore?
From: CC <crobc@BOGUS.sbcglobal.net>
Date: Tue, 23 Jan 2007 22:09:51 -0800
Links: << >>  << T >>  << A >>
Hi:

I used to use the Xilinx Constraints Editor (XCE) (right click on the 
.ucf file under my source file, and open it) in Webpack 5.2i to assign 
nets to pins for Coolrunner XPLA3 projects.

Now I have updated to 8.2i (oh, why!?!?) and I find that when I open a 
.ucf file with the XCE, that in the ports tab, location column, all are 
read-only.  That is, I can't enter pins here anymore.

I have figured out how to use PACE, but I don't like it.  I like XCE.

Hmm, now I see XCE has this new "Constraints Window" that has a tab: 
"Source Constraints (read-only)" which lists the pin constraints.

Now why did they do that?

Is it impossible to use XCE to set pins anymore?

Thanks.



-- 
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5

Article: 114765
Subject: Re: R: iMPACT dont shows erase write options with fpga
From: Sean Durkin <news_jan07@durkin.de>
Date: Wed, 24 Jan 2007 07:11:30 +0100
Links: << >>  << T >>  << A >>
Ben Jackson wrote:
> Drunk is the right state to use iMPACT.  For example, if you go back and
> forth between writing .bit's into FPGAs and .mcs's into Xilinx config
> proms, you will want to stab someone each time you forget to turn ON
> erase/verify/use-internal-config-clock for the PROM because iMPACT
> mysteriously forgot those settings... AGAIN
One of numerous quirks... In ISE8.2 SP3, iMPACT just crashes if you dare
to rename or move the bitfile that is currently assigned.

And has anyone noticed that it uses two different file selection boxes?
If you detect the JTAG-chain and it finds a device, it prompts you
automatically to select a corresponding bitfile. The selection box is
"old style"; for example you can't enter network paths manually, and the
drop-down list for drive selection only shows the drive letters, not the
names. So imagine you have 4 or 5 network shares mapped and you just
cannot remember if the one the bitfile is on was X:, Y: or Z:... Very
annoying. But if you assign a new bitfile later on (e.g. by
right-clicking the device and selecting "Assign new bitfile"), you get a
completely different file selection box, the standard one more or less
all Windows applications use now.
So obviously two different people worked on that, two different codes
for the same thing. Not a "problem" per se, but it makes you wonder...
if things like that are common in other parts of ISE, it might explain
certain "This only works when I do it like this but not when I do it
like that"-effects.

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 114766
Subject: Re: Xilinx ISE 8.2
From: Sean Durkin <news_jan07@durkin.de>
Date: Wed, 24 Jan 2007 07:19:31 +0100
Links: << >>  << T >>  << A >>
bgshea wrote:
> WOW, thanks everyone for the input. I'm going to dig though this info
> and esp. the links provided.
> 
> I would love to see some linux build scripts. I love EMACS!! and use it
> for all my c/c++ developement in linux. However, i don't have a PC to
> space in my office for linux yet. But i can certainly try on one of my
> personal Linux boxes.
Xemacs including VHDL mode is available for Windows as well. And you can
install Cygwin (http://www.cygwin.com) on any Windows box to get an
almost complete UNIX-like environment, with Bash, grep, sed, awk, make,
Perl, whatever you need to run build scripts.

cu,
Sean

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 114767
Subject: Re: digilent nexys vga glitches
From: "Corer" <corer@somewhere.net>
Date: Wed, 24 Jan 2007 06:36:48 GMT
Links: << >>  << T >>  << A >>
Thank you for your time Red.
I was able to access the url and did the following:
    - copied the squares code into a brand new vhdl
       project created with Xilinx ISE 7.1i
    - changed clk50 into clk25 (see below for full vhdl code)
    - flipped the clock jumper on Nexys to 25MHz
    - assigned pins (see .ucf below)
    - Changed "Generate Programming File"
      FPGA Start-Up Clock option to JTAG Clock
    - Added one timing constraint "25 MHz HIGH 50 %"
      to clk25 signal in Xilinx Constraints Editor
    - have not touched anything else in the project
    - Built the project
    - Uploaded it onto Nexys using ExPort

And I'm still getting the scanline jitter on my monitor.
Could you try to run my code (below) on you nexys and
say whether the picture is perfectly stable?

> Doubt your oscillator is bad if you are seeing anything.
> Try a simple divide by 2 or 4 circuit and check the output with your
> scope.
25MHz looks like a 25MHz square wave (it rings just a little bit)
1000ns after-trigger-delayed trace shows "thicker" edges (due to jitter)

> Have you stipulated a constraint of 100MHz input for the mClk
> pin to see if your design can run at that speed?
> 10ns clock period doesn't leave much room to play with.
I've changed my clock to 25MHz and set the timing constraint.
xilinx tools displayed the following:
----------------------------------------------------------------------------
----
  Constraint                                | Requested  | Actual     |
Logic
                                            |            |            |
Levels
----------------------------------------------------------------------------
----
  TS_clk25 = PERIOD TIMEGRP "clk25" 25 MHz  | 40.000ns   | 7.366ns    | 3
  HIGH 50%                                  |            |            |
----------------------------------------------------------------------------
----


>
> vertical count is not synchronized to the horizontal count.
I tried dependent counters as well... Thanks for noting this though.



============== squares.ucf ==============
NET "clk25" TNM_NET = "clk25";
TIMESPEC "TS_clk25" = PERIOD "clk25" 25 MHz HIGH 50 %;
#PACE: Start of Constraints generated by PACE

#PACE: Start of PACE I/O Pin Assignments
NET "blue_out"  LOC = "L15"  ;
NET "clk25"  LOC = "A8"  ;
NET "green_out"  LOC = "N15"  ;
NET "hs_out"  LOC = "R6";
NET "red_out"  LOC = "P16"  ;
NET "vs_out"  LOC = "R7";

#PACE: Start of PACE Area Constraints

#PACE: Start of PACE Prohibit Constraints

#PACE: End of Constraints generated by PACE


============== squares.vhd ==============
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity clockmodule is
  port(clk25     : in  std_logic;
       red_out   : out std_logic;
       green_out : out std_logic;
       blue_out  : out std_logic;
       hs_out    : out std_logic;
       vs_out    : out std_logic);
end clockmodule;

architecture Behavioral of clockmodule is

signal horizontal_counter : std_logic_vector (9 downto 0);
signal vertical_counter   : std_logic_vector (9 downto 0);

begin

process (clk25)
begin
  if clk25'event and clk25 = '1' then
    if (horizontal_counter >= "0010010000" ) -- 144
    and (horizontal_counter < "1100010000" ) -- 784
    and (vertical_counter >= "0000100111" ) -- 39
    and (vertical_counter < "1000000111" ) -- 519
    then
      red_out <= horizontal_counter(3)
            and vertical_counter(3);
      green_out <= horizontal_counter(4)
            and vertical_counter(4);
      blue_out <= horizontal_counter(5)
            and vertical_counter(5);
    else
      red_out <= '0';
      green_out <= '0';
      blue_out <= '0';
    end if;
    if (horizontal_counter > "0000000000" )
      and (horizontal_counter < "0001100001" ) -- 96+1
    then
      hs_out <= '0';
    else
      hs_out <= '1';
    end if;
    if (vertical_counter > "0000000000" )
      and (vertical_counter < "0000000011" ) -- 2+1
    then
      vs_out <= '0';
    else
      vs_out <= '1';
    end if;
    horizontal_counter <= horizontal_counter+"0000000001";
    if (horizontal_counter="1100100000") then
      vertical_counter <= vertical_counter+"0000000001";
      horizontal_counter <= "0000000000";
    end if;
    if (vertical_counter="1000001001") then
      vertical_counter <= "0000000000";
    end if;
  end if;
end process;

end Behavioral;

============== end of vhdl ==========

Corer.



From invalid@dont.spam Tue Jan 23 22:42:36 2007
Path: newssvr13.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!nx02.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny05.POSTED!933f7776!not-for-mail
From: Phil Hays <invalid@dont.spam>
Subject: Re: Xilinx ISE 8.2
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table)
Message-Id: <pan.2007.01.24.06.45.49.874398@dont.spam>
Newsgroups: comp.arch.fpga
References: <1169489849.344862.112520@51g2000cwl.googlegroups.com> <ep5es2$vv2@cnn.xsj.xilinx.com> <12rcrgff947a4e5@corp.supernews.com> <1169589412.427666.58670@k78g2000cwa.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 30
Date: Wed, 24 Jan 2007 06:42:36 GMT
NNTP-Posting-Host: 71.112.133.239
X-Complaints-To: abuse@verizon.net
X-Trace: trndny05 1169620956 71.112.133.239 (Wed, 24 Jan 2007 01:42:36 EST)
NNTP-Posting-Date: Wed, 24 Jan 2007 01:42:36 EST
Xref: prodigy.net comp.arch.fpga:125992

bgshea wrote:

> ISE has been, IMHO, going down hill. With each new release the projects
> become backward incompatible.

Perhaps you should try script based builds such Tcl or makefiles, and use
a source control program such as SVN.

Tcl or "tool control language" is a industry standard language. Documented
Tcl was new with 8.2, and in my never humble opinion was a big step
forward. I've taken a design I'm working on between 8.2 and 9.1 and back
again several times without changing the Tcl script. Nice section on Tcl
in the manual.


A source control program will allow you to have access to any past
revision of your code, to show the differences between each revision,
allow changes to be reverted (or backed out). It also makes it easier to
work on multiple machines, or for multiple people to work on the same
design.

http://subversion.tigris.org/

As you like emacs, you might also like this:

http://www.xsteve.at/prg/vc_svn/index.html


-- 
Phil Hays (Xilinx, but always speaking for myself)

Article: 114768
Subject: Re: Xilinx ISE 8.2
From: Sean Durkin <news_jan07@durkin.de>
Date: Wed, 24 Jan 2007 08:03:10 +0100
Links: << >>  << T >>  << A >>
doug wrote:
> ISE has been an experience.  By version 6.3 it was reasonably
> good.  It did what I wanted and did not cause too much trouble.
> Version 7 was a huge step backwards.  Project navigator got user
> surly and very slow.  Whoever did the design never used it for
> anything.  Version 8 reached a new low.  The stupid design to
> change the project files, later partly removed, made for lots of
> headaches.

I think the main problem is that Xilinx releases new ISE versions in a
predefined schedule, as Austin mentioned in Antti's thread about
non-volatile Xilinx-FPGAs. A new ISE release comes out regularly, not
when it's done. But on the other hand, it doesn't make sense to release
a new version, when there's nothing new in it. The marketing department
has to brag about it being another 30% faster than the previous release,
having gazillions of new features, and so on.
This approach results in the software department always being busy
integrating new features so they can make the fixed deadline for the new
software release, resulting in software that's usually not usable until
three service packs later, and just when it finally *IS* usable, support
is dropped because the next release comes out and it all starts over again.

Sometimes you get the idea that a new ISE is not just a new software
version, but an entirely new product. Maybe it was just quicker to start
from scratch than to fix what was already there. And then you get
effects like bugs that were fixed in 7.1 re-appearing in 8.1 and things
like that...

We had a Xilinx FAE here in late November, introducing us to Virtex-5,
and when the topic of bugs in ISE came up, he actually said that we
needn't bother sending in bug reports now, since the entire software
department at Xilinx was now scrambling to make the deadline for the 9.1
release and nothing would really happen until after that anyway. And bug
reports for ISE8.2 were useless anyway, since all the work is going into
9.1 now...

Add to this the additional support for Linux (which wasn't there before
6.3, I believe, and which I highly appreciate, BTW), and you get a
situation where even competent programmers can't produce decent
software, IMHO.

What is it with that regular release cycle? Does any other FPGA
manufacturer do this? Or any other software company? What good is it?
Customers have licenses, that are valid for one year, so you have to pop
out one release a year so they get something for their money or what? I
don't really get it. Software-quality-wise it does not make sense at all
IMHO.

And then things like Antti mentioned happen: ISE9.1 is out, and it has
support for devices that aren't even announced yet, i.e. no small
customer is going to get for another year anyway. Why not just fix some
bugs instead of integrating phantom devices? Why not just fix what's
broken instead of adding even more new stuff that's broken as well?

Partial reconfiguration is another example. I've been fiddling around
with this since ISE4, gave up with ISE7, since I always ran into some
"FATAL_ERROR"-thingies that "will be fixed in the next service pack" or
"will be fixed in the next ISE release", but never were. Now with
software radio being a high-volume-application, they seem to have fixed
it, but only in specially patched ISE8-versions you have to get through
your FAE.

And does anyone besides me think that it's ridiculous to release the
first service pack only days after the software? Doesn't that in itself
tell you that obviously the software wasn't ready to be released in the
first place? Service pack sizes of > 300MB, where basically every single
file in the installation is replaced, aren't a good sign either.

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 114769
Subject: Re: R: iMPACT dont shows erase write options with fpga
From: Ben Jackson <ben@ben.com>
Date: Wed, 24 Jan 2007 01:30:50 -0600
Links: << >>  << T >>  << A >>
On 2007-01-24, Sean Durkin <news_jan07@durkin.de> wrote:
> One of numerous quirks... In ISE8.2 SP3, iMPACT just crashes if you dare
> to rename or move the bitfile that is currently assigned.

That's probably related to the fact that you can't assign a new one.
The menu option is there, and if you select it you get the bit/bmm/etc
dialog, but if you select the old .bit file, "remove" stays grayed out.
I end up rediscovering the chain to have another go at assigning a file.
Since it doesn't really remember my settings for the prom or cpld anyway
it hardly matters...

And considering the tool can't remember settings WHILE it's running, why
is it so rabid about having you work within an open "project" which it
wants to save for you?

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 114770
Subject: Re: system generator from Xilinx
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 24 Jan 2007 02:43:51 -0500
Links: << >>  << T >>  << A >>
Since nobody wants to answer... I don't have any practical experience with
sysgen, but here is what I know:

1. It seems that Xilinx uses sysgen internally to develop their new cores.
As a result some of the newer cores are not available through coregen, but
only through sysgen or through a special request for a netlist. For example,
take a look at their DUC core or at the Continuously Variable Fractional
Rate Decimator described in the appnote XAPP936.

2. Sysgen in concert with MATLAB Simulink seems to be a nice tool helping to
visualize what happens with the signal. However I am not at all sure this
tool won't be an annoying extra layer of complexity when designing low level
interfaces between the modules.

3. Sysgen + Simulink cost a lot of money.


/Mikhail


<nbg2006@gmail.com> wrote in message
news:1169404354.471231.198040@s34g2000cwa.googlegroups.com...
> Hello all,
> I just wanted to find out how good system generator software is? I can
> program in VHDL and would like to know if the SYS gen software would
> make life easier for me when it comes to designing DSP filters , FFTS
> or other DSP blocks.
> Does Xilinx  provide IPs separately for the DSP blocks? If so then How
> different is it from using Xilinx IP in the design instead of sysgen
> blocks ?
> Any experience on system generator software would be helpful .
> Thanks,
> nbg
>



Article: 114771
Subject: Re: Surface mount ic's
From: David R Brooks <davebXXX@iinet.net.au>
Date: Wed, 24 Jan 2007 00:33:21 -0800
Links: << >>  << T >>  << A >>
pbFJKD@ludd.invalid wrote:
>>>>> Now all you need is a Gerber-driven solder paste dot printer! They 
>>>>> exist, and news of an affordable unit for prototyping would be interesting.
>>>> Following up myself, the Essemtec CDS6700 solder paste printer seems to 
>>>> cost around $25,000. Not quite affordable ;-)
>>> Makes me wonder what it would cost to build x-y table and reuse a inkjet
>>> cartridge ;)
> 
>> Maybe with a DVD inkjet printer (like Epson R200), should hold a Eurocard 100x160.
>> DVD is 120mm wide, it is in a tray that slides through the printer, no length limit.
>> Costs 80 Euro to try...
> 
> Do you think the solderpaste would get through the ink channels ..?
> Maybe it's viscosity is too high.
> 
> I also think that any ordinary underpriced inkjet will be just fine. Just
> bring the screwdriver. On a more serious side, increasing the distance
> between printheads and printer bottom. Then add some wagon to fasten the
> pcb into which is driven by the paperfeed mechanism.
> 
> I think the real blocker is the ink channel mechanism, once that is solved it
> depend mainly on precision of x-y table + diameter of the solderpaste drop.
> 5-10 mil should be enough precision on the maximum side?
> 
How about an old scanner, turned upside down, with the optics replaced 
by a paste syringe, pumped by either a stepper motor & leadscrew, or by 
something generating pulses of air pressure (which is how the 
professional rework stations do it)?

Article: 114772
Subject: Re: Xilinx ISE 8.2
From: jesse lackey <jesse@celestialaudio.com>
Date: Wed, 24 Jan 2007 08:45:22 GMT
Links: << >>  << T >>  << A >>
doug wrote:
> Memory leaks come from sloppy programmers.  Not fixing memory leaks
> comes from lazy or incompetent programmers.  It is clear that the
> programmers did not test their code.  They seem to think that "testing"
> means looking to see if it blows up in the first ten seconds.  This is

Actually, memory leaks are just another bug, like any other, better 
programmers will have fewer of them than worse/sloppy programmers. 
There will be bugs.  Testing is QA's responsibility.  The decision to 
fix things is up to project management.

The fault of ISE rather clunky behavior and problems - I'm a newbie 
here, been using it for a few days and 600 lines of VHDL - can be laid 
at the feet of middle managment at Xilinx.  If one feels insulted and 
frustrated that Xilinx doesn't believe it is worth it to prioritize 
fixing longstanding issues, then you have to vote with your qty 10,000 
design decisions.  It is the only thing that makes businesspeople really 
listen.

I've seen some of the problems mentioned here already.  Process "_pn" 
hanging around.  Multi-second lag times to start tools.  Weird project 
setting problems in iMpact or whatever it is called (fortunately I just 
use it to make a hex file I process with a script to make a const array 
in C for the microcontroller code).  Somewhat disappointing but so far 
no synthesis bugs.

To ISE's credit, having error messages have a link to knowledgebase 
articles on xilinx.com has been very handy.  Smart.

J

Article: 114773
Subject: Re: "Divide" a video line in two stripe
From: "jbnote" <jbnote@gmail.com>
Date: 24 Jan 2007 00:45:27 -0800
Links: << >>  << T >>  << A >>
Wow, that's cool.

JB


Article: 114774
Subject: Re: Surface mount ic's
From: pbFJKD@ludd.invalid
Date: 24 Jan 2007 09:02:21 GMT
Links: << >>  << T >>  << A >>
>> I think the real blocker is the ink channel mechanism, once that is solved it
>> depend mainly on precision of x-y table + diameter of the solderpaste drop.
>> 5-10 mil should be enough precision on the maximum side?
>> 
>How about an old scanner, turned upside down, with the optics replaced 
>by a paste syringe, pumped by either a stepper motor & leadscrew, or by 
>something generating pulses of air pressure (which is how the 
>professional rework stations do it)?

Add a printer "x-drive" to the scanner and the x-y is complete.
Syringe pumped with leadscrew might work, albeit possible slow. The air
pressure approach together with a magnetic valve may also work.

What do you think about a combined camera + very thin soldering iron to
completly rid of the oven stage..?




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