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 157500

Article: 157500
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: "hvo" <91991@embeddedrelated>
Date: Fri, 12 Dec 2014 17:00:57 -0600
Links: << >>  << T >>  << A >>
Thank you, this has been very helpful for me.  I feel like a small light
bulb turned on in my head, though its fluorescent and it flickers on a off
a bit before staying on :)

I think we can agree that metastability is bad and a dual flip flop on an
input signal can resolve this.  We can add more FF in series to get the
probability of a metastability event down to "zero", but lets say that two
is good enough.  Back to my original question is how would one do this for
a large design with many inputs?

Consider my sample code below, lets say I have a design that has 85 inputs.
 To synchronized everything with dual FF would require 170 internal
signals.  No big deal if you have an large enough FPGA, but is this a
realistic thing to do?   In a CPLD this would take up a lot of resources.

How many out there are actually doing this?  
Is there a better way of doing it?

---------------------------------------------------------------------------------
--  Sample code - Dual FF on all input?
---------------------------------------------------------------------------------
entity BigDesign is
port(
 Clk : in std_logic;
 IN1 : in std_logic;
 .
 .
 .
 .
 .
 IN85 : in std_logic;
 out  : out std_logic
 );
end BigDesign;

archictecture behavioral of BigDesign is

Signal IN1_meta : std_logic;
signal IN1_Sync : std_logic;

Article: 157501
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 12 Dec 2014 15:13:59 -0800 (PST)
Links: << >>  << T >>  << A >>
Gabor, to be clear, I posted that information
from the point of view: "This is where I got my
info. In case I'm wrong, someone could correct
me." I wasn't trying to correct you. I'm still not
100% sure what it means.

Best regards,
Rick C. Hodgin

Article: 157502
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Fri, 12 Dec 2014 15:18:38 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Dec 2014 17:00:57 -0600
"hvo" <91991@embeddedrelated> wrote:

> Thank you, this has been very helpful for me.  I feel like a small light
> bulb turned on in my head, though its fluorescent and it flickers on a off
> a bit before staying on :)
> 
> I think we can agree that metastability is bad and a dual flip flop on an
> input signal can resolve this.  We can add more FF in series to get the
> probability of a metastability event down to "zero", but lets say that two
> is good enough.  Back to my original question is how would one do this for
> a large design with many inputs?
> 
> Consider my sample code below, lets say I have a design that has 85 inputs.
>  To synchronized everything with dual FF would require 170 internal
> signals.  No big deal if you have an large enough FPGA, but is this a
> realistic thing to do?   In a CPLD this would take up a lot of resources.
> 
> How many out there are actually doing this?  
> Is there a better way of doing it?
> 
> ---------------------------------------------------------------------------------
> --  Sample code - Dual FF on all input?
> ---------------------------------------------------------------------------------
> entity BigDesign is
> port(
>  Clk : in std_logic;
>  IN1 : in std_logic;
>  .
>  .
>  .
>  .
>  .
>  IN85 : in std_logic;
>  out  : out std_logic
>  );
> end BigDesign;
> 
> archictecture behavioral of BigDesign is
> 
> Signal IN1_meta : std_logic;
> signal IN1_Sync : std_logic;

Once again, sometimes you would and sometimes you wouldn't.  Let's take
the fairly common case of an 8-bit data bus with an active low latch
signal.  The falling edge of the latch indicates that the data is
valid, and that you should latch it.

In this case, the only thing that actually requires synchronization is
the latch signal itself.  Once you resynchronize it, and see that the
new value of that synced signal is 0 whereas it used to be 1, then you
can latch the 8-bit data presented because you know that it's stable
(by contract) at the time of the falling latch.

Now, the time it takes you to delay may violate that contract; if your
two flip-flops are on a 100 MHz clock that's 20 ns; if you're only
guaranteed 20 ns of data valid then you need to add 1 level of
registers on all that data too.  But that's not there to deal with
metastability, it's just there to try to match your delays up because,
on the clock when you latch the data than you intend to be latched by
the falling-edge detector, the data will be stably 0 or 1 and so
there's no metastability risk. 

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157503
Subject: Re: Using FPGA to feed 80386
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 12 Dec 2014 17:56:29 -0600
Links: << >>  << T >>  << A >>
On Fri, 12 Dec 2014 19:33:27 +0000, Theo Markettos wrote:

> Tim Wescott <seemywebsite@myfooter.really> wrote:
>> I think the OP needs to learn a bit more about the wonderful world of
>> logic levels (and Rick H. -- feel free to ask).
> 
> My feeling would be to try and avoid using 5V parts.  For instance, the
> Intel Quark 1000 is a 400MHz Pentium-class CPU being aimed at
> microcontroller applications.  It probably isn't quite as easy to manage
> (it's a BGA package not a PLCC) but is rather more modern.
> 
> The Quark itself is a bit of a camel, but it's the modern equivalent of
> a 386.  The alternative would be an Atom, VIA or some other 'embedded'
> x86 processor.  All of these might be harder to handle than the slower
> 386 though.  The Quark comes on the Intel Galileo board which can be
> connected to the Cyclone V GX via PCIe, which is one way to join them.
> 
>> My inclination is that if the guy needs to make a board anyway, he may
>> as well put the FPGA on it, and not mess around trying to make a board
>> to stick onto the starter kit.  I don't know enough about the parts
>> involved to know if, at that point, he can get away with putting them
>> together without level translators or not.  I suspect not -- I'll bet
>> that 386 has 5V CMOS-level inputs, and that the Altera part can't be
>> run with 5V on the I/O.  But I am NOT going to take the time to dig
>> through data sheets -- the OP can do that as part of his education in
>> digital hardware design.
> 
> I'd suggest the OP avoid making an FPGA board: a 6/8 layer board with a
> ton of low-voltage high-current FPGA power supplies, BGA escapes, signal
> integrity etc, is a somewhat more complex endeavour than a basic-ish 2/4
> layer board to hook into an expansion header on the existing board.  Not
> least because you can design that in a free/cheap tool, you don't have
> to pay for fancy PCB tools, and you can get it fabbed anywhere.
> 
> I very much doubt it'll be possible without level translators, which
> doubles the complexity of the addon board.
> 
> Theo

If he can't find an FPGA in something other than BGA packaging then yes -- 
you're right.  And, he probably would need an FPGA with enough I/O to be 
in a BGA.  So again...

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 157504
Subject: Re: Using FPGA to feed 80386
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 12 Dec 2014 18:04:04 -0600
Links: << >>  << T >>  << A >>
On Thu, 11 Dec 2014 14:26:42 -0800, Rick C. Hodgin wrote:

> On Thursday, December 11, 2014 5:11:44 PM UTC-5, Tim Wescott wrote:
>> On Thu, 11 Dec 2014 11:55:14 -0800, Rick C. Hodgin wrote:
>> 
>> > Would it be possible to connect an FPGA up to an 80386 (or other)
>> > CPU, to respond to memory and port requests, and leverage it as a
>> > resource?
>> > 
>> > I'm thinking software runs on the 80386, given it by the FPGA,
>> > instructing it as a type of co- processor, which does things on
>> > command.
>> > 
>> > I see voltage differences as an issue.
>> > 
>> > Best regards,
>> > Rick C. Hodgin
>> 
>> Are you doing this to have fun playing with obsolete processors, or do
>> you have a job to do?
>> 
>> If it's the former -- have fun.
>> 
>> If it's the latter -- you are aware that there are all sorts of far
>> more modern solutions to this general problem than the one you're
>> proposing, yes?
> 
> It's a mental exercise right now.  I have never considered anything
> about hardware in my past.  I'm a software guy, and always thought of
> hardware as being outside of my reach.  However, a short time ago I was
> introduced to Verilog and the FPGA.  Since then I've had this flood of
> ideas on how things might work ... so, I ask questions. :-)
> 
> I do have an old 80386-16 MHz ceramic CPU (several actually), along with
> 80486 through Pentium various models (some of which are 3.3V), along
> with AMD K5, etc.
> 
> I was basically just thinking through the process.
> 
> Best regards,
> Rick C. Hodgin

Hey Rick:

I don't know where a good place to put this is, so I'll put it here.

What you needed to do to answer your question was to look at the data 
sheets for the FPGA and processor in question, and look at the schematic 
of the FPGA test board.

The data sheet for the processor will have four numbers that are pertinent 
to this problem: the input high voltage, the input low voltage, the output 
high voltage, and the output low voltage.

The FPGA data sheet will have those same four numbers, except that FPGAs 
often let you power up different I/O banks with different supplies.  In 
addition (if you can't power up an I/O bank with 5V), the FPGA data sheet 
will tell you if the thing can tolerate voltages higher than the power 
rail.

Leaving the board schematic out of it (because we know there's a gotcha 
there), you match up the input high voltage of a receiving chip with the 
output high voltage of a transmitting chip.  If the latter is greater than 
the former, and the output high voltage isn't greater than the voltage 
that the receiving chip can stand, then that connection is OK.  You need 
to do this for ALL THE PINS ON BOTH CHIPS, although usually those five 
numbers are the same for all pins on their respective chips.

Had you done this, and found it good, you'd still have those diodes on the 
FPGA board (they're protection diodes, to prevent software guys from 
damaging the hardware :) ).

This is just one of the tasks that you need to do any time you're going to 
marry two chips on a board.  It's easier if everything is CMOS and 
operates on the same power rail -- in that case, you're probably OK.  But 
as soon as thing 1 operates at one voltage and thing 2 operates at 
another, you have to dig through all this stuff, and put in level 
translators if the chips themselves aren't up to snuff.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 157505
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 19:28:01 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 6:18 PM, Rob Gaddi wrote:
> On Fri, 12 Dec 2014 17:00:57 -0600
> "hvo" <91991@embeddedrelated> wrote:
>
>> Thank you, this has been very helpful for me.  I feel like a small light
>> bulb turned on in my head, though its fluorescent and it flickers on a off
>> a bit before staying on :)
>>
>> I think we can agree that metastability is bad and a dual flip flop on an
>> input signal can resolve this.  We can add more FF in series to get the
>> probability of a metastability event down to "zero", but lets say that two
>> is good enough.  Back to my original question is how would one do this for
>> a large design with many inputs?
>>
>> Consider my sample code below, lets say I have a design that has 85 inputs.
>>   To synchronized everything with dual FF would require 170 internal
>> signals.  No big deal if you have an large enough FPGA, but is this a
>> realistic thing to do?   In a CPLD this would take up a lot of resources.
>>
>> How many out there are actually doing this?
>> Is there a better way of doing it?
>>
>> ---------------------------------------------------------------------------------
>> --  Sample code - Dual FF on all input?
>> ---------------------------------------------------------------------------------
>> entity BigDesign is
>> port(
>>   Clk : in std_logic;
>>   IN1 : in std_logic;
>>   .
>>   .
>>   .
>>   .
>>   .
>>   IN85 : in std_logic;
>>   out  : out std_logic
>>   );
>> end BigDesign;
>>
>> archictecture behavioral of BigDesign is
>>
>> Signal IN1_meta : std_logic;
>> signal IN1_Sync : std_logic;
>
> Once again, sometimes you would and sometimes you wouldn't.  Let's take
> the fairly common case of an 8-bit data bus with an active low latch
> signal.  The falling edge of the latch indicates that the data is
> valid, and that you should latch it.
>
> In this case, the only thing that actually requires synchronization is
> the latch signal itself.  Once you resynchronize it, and see that the
> new value of that synced signal is 0 whereas it used to be 1, then you
> can latch the 8-bit data presented because you know that it's stable
> (by contract) at the time of the falling latch.
>
> Now, the time it takes you to delay may violate that contract; if your
> two flip-flops are on a 100 MHz clock that's 20 ns; if you're only
> guaranteed 20 ns of data valid then you need to add 1 level of
> registers on all that data too.  But that's not there to deal with
> metastability, it's just there to try to match your delays up because,
> on the clock when you latch the data than you intend to be latched by
> the falling-edge detector, the data will be stably 0 or 1 and so
> there's no metastability risk.

I will add that you don't need two *additional* FFs for each input.  It 
is not the FF that deals with metastability, it is the slack time in the 
path to the next FF.  So you only need to add one FF per input with no 
logic (or sometimes you can violate that rule if the logic is simple and 
you use a timing constraint to provide guaranteed slack) in the path to 
the next FF.  Really, it is not how much logic there is, the issue is 
slack time to resolve the metastable event before reaching the next FF. 
  So in theory, even a path with no logic can have a bad route with very 
little slack time if the clock is fast enough.

I've never done this, but it would be good practice to use a separate 
timing constraint to assure slack time on the path you are using to 
resolve the metastable events on the input.

-- 

Rick

Article: 157506
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 12 Dec 2014 16:41:54 -0800 (PST)
Links: << >>  << T >>  << A >>
In researching the 80386 datasheet, I came
across a comment that said a later version of
the 80386 core was completed in "fully static
CMOS," whatever that means, for a couple
devices, as per the wiki:

http://en.m.wikipedia.org/wiki/Intel_80386 

Best regards,
Rick C. Hodgin

Article: 157507
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 21:30:50 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 6:13 PM, Rick C. Hodgin wrote:
> Gabor, to be clear, I posted that information
> from the point of view: "This is where I got my
> info. In case I'm wrong, someone could correct
> me." I wasn't trying to correct you. I'm still not
> 100% sure what it means.
>
> Best regards,
> Rick C. Hodgin

The 5 volt pin is a power source from the FPGA board to the cable.  It 
can supply 1 amp of current.  "and also provides DC +5V (VCC5)" says 
this is separate from the FPGA I/Os.

To learn about the I/O voltages the FPGA supports you need to read the 
pin definitions of the I/Os from the FPGA in the eval board manual. 
This will be determined by the voltage supplied to the FPGA from the 
eval board as well as the configuration used in the FPGA.  Even with a 
given voltage, there can be multiple I/O standards.

-- 

Rick

Article: 157508
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Dec 2014 21:48:45 -0500
Links: << >>  << T >>  << A >>
On 12/12/2014 7:41 PM, Rick C. Hodgin wrote:
> In researching the 80386 datasheet, I came
> across a comment that said a later version of
> the 80386 core was completed in "fully static
> CMOS," whatever that means, for a couple
> devices, as per the wiki:
>
> http://en.m.wikipedia.org/wiki/Intel_80386

In early processors from Intel they used dynamic logic which used 
capacitance to store voltages rather than FFs.  This voltage would leak 
away if it was not constantly refreshed, so there was a maximum clock 
period.  That was all about saving space in the chip, but it required 
complicated multi-phase clocks.

As the process geometries got smaller and they could pack more onto the 
chip they started using clocked FFs which have no maximum clock period 
and so are "static".

-- 

Rick

Article: 157509
Subject: Re: VHDL Synchronization- two stage FF on all inputs?
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 13 Dec 2014 14:48:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 12, 2014 6:01:00 PM UTC-5, hvo wrote:
>=20
> I think we can agree that metastability is bad and a dual flip flop on an
> input signal can resolve this.  We can add more FF in series to get the
> probability of a metastability event down to "zero", but lets say that tw=
o
> is good enough.  Back to my original question is how would one do this fo=
r
> a large design with many inputs?

Read the last paragraph of my Dec 10 post for the short answer.  Whether a =
design has a large or small number of inputs is not relevant.  What you nee=
d to know is the clock that is used to generate those inputs from their ext=
ernal source.

>=20
> Consider my sample code below, lets say I have a design that has 85 input=
s.
>  To synchronized everything with dual FF would require 170 internal
> signals.  No big deal if you have an large enough FPGA, but is this a
> realistic thing to do?   In a CPLD this would take up a lot of resources.
>=20

No flip flops are needed if:
- In1...In85 are generated synchronous to Clk
- The setup and hold time requirements of In1...In85 to your design are met=
.

> How many out there are actually doing this? =20
> Is there a better way of doing it?
>=20

You need to study up on how to perform static timing analysis.  As I mentio=
ned in my first post, what you're struggling with has nothing to do with me=
tastability.  What it does have to do with is simply timing analysis.  As a=
n example, if In1...In85 all are guaranteed to arrive at the input pins bet=
ween 1 and 5 ns after the rising edge of a 10 ns clock period Clk input, an=
d the setup time for your design requires 3 ns of setup time and 0 ns of ho=
ld time, then you have sufficient margin.  If the setup time requirement of=
 In43 happens to be 6 ns then you have a 1 ns problem on one input that nee=
ds to be fixed.

All of this information comes out of the timing report.  The input to the t=
iming report is the routed design and the timing constraints (in the above =
case that In1...In85 all have between 1 and 5 ns of delay).

Kevin Jennings

Article: 157510
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 10:47:45 -0800 (PST)
Links: << >>  << T >>  << A >>
How would I go about making my own boards?
I am aware of commercial companies which
have software you can download, and construct
the layout through their process manufacturing,
and you will receive boards and solder masks.

But are there things you can do yourself? Buy a
blank copper layer, cover with a photoresist,
expose a mask, and then chemically etch away
the exposed or unexposed are (depending on
the resist)?

Best regards,
Rick C. Hodgin

Article: 157511
Subject: Re: Using FPGA to feed 80386
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 14 Dec 2014 14:51:31 -0500
Links: << >>  << T >>  << A >>
On 12/14/14, 1:47 PM, Rick C. Hodgin wrote:
> How would I go about making my own boards?
> I am aware of commercial companies which
> have software you can download, and construct
> the layout through their process manufacturing,
> and you will receive boards and solder masks.
>
> But are there things you can do yourself? Buy a
> blank copper layer, cover with a photoresist,
> expose a mask, and then chemically etch away
> the exposed or unexposed are (depending on
> the resist)?
>
> Best regards,
> Rick C. Hodgin
>

Yes, there are home kits for building boards. Unless you go VERY fancy, 
you will be limited to 2 sided boards, and likely do NOT have plated 
through holes, so you need to solder through jumpers to get from one 
side to the other.

Generally, the line width you can make with this sort of system isn't 
any where near what you can do with commercial fabrication.

If you are only planning a few boards, it may be cheaper to use some of 
the short run prototype shops, as there is a moderate investment in 
tools to be able to make your own boards.

Article: 157512
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Sun, 14 Dec 2014 18:56:20 -0500
Links: << >>  << T >>  << A >>
On 12/14/2014 1:47 PM, Rick C. Hodgin wrote:
> How would I go about making my own boards?
> I am aware of commercial companies which
> have software you can download, and construct
> the layout through their process manufacturing,
> and you will receive boards and solder masks.
>
> But are there things you can do yourself? Buy a
> blank copper layer, cover with a photoresist,
> expose a mask, and then chemically etch away
> the exposed or unexposed are (depending on
> the resist)?

I don't bother with that anymore.  I think I made one or two PCBs back 
in my misspent youth though.  It is a messy, somewhat complex and 
unrewarding task to make crude PCBs yourself and then you have corrosive 
chemicals to dispose of.  Even assembly of PCBs is a PITA in my opinion 
although I will do a little work on them.  But this is my perspective 
where my eyes and hands are nowhere near as good as they used to be even 
if my patience is a lot better.

I much prefer to let contract assembly houses do my dirty work for me. 
PCBs can be downright cheap if you limit them to 4 layers.  There are a 
number of places which will batch numerous user's boards to make panels 
(the size that the PCB fabricator produces) and then ship everyone their 
individual boards.  Oshpark is one I have seen a lot of.  ITEAD provides 
a similar service and will also do the assembly.  Then I just read about 
dirtypcbs.com who also make cheap PCBs.

FPGAs are easy because you can test your code in a simulator and reload 
in the hardware anything that doesn't work.  Actual hardware is not so 
easy and mistakes can get expensive.  You need to start small and work 
your way up.  Laying out a board has a *lot* of pitfalls.  With a $50 to 
$100 worth of parts on the board you don't want to mess it up too many 
times.

-- 

Rick

Article: 157513
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 16:03:17 -0800 (PST)
Links: << >>  << T >>  << A >>
I found this video. It was interesting. Also some
instructables on the process.

    http://www.youtube.com/watch?v=tWnfnt2rNO0

Best regards,
Rick C. Hodgin

Article: 157514
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 16:50:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Even better:

    http://m.youtube.com/#/watch?v=4SNkzoOvoD8

Best regards,
Rick C. Hodgin

Article: 157515
Subject: Re: Using FPGA to feed 80386
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 15 Dec 2014 00:54:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> How would I go about making my own boards?
> I am aware of commercial companies which
> have software you can download, and construct
> the layout through their process manufacturing,
> and you will receive boards and solder masks.
 
> But are there things you can do yourself? Buy a
> blank copper layer, cover with a photoresist,
> expose a mask, and then chemically etch away
> the exposed or unexposed are (depending on
> the resist)?

You can do that for 1 and 2 layers, and if you don't need tight
tolerance.  You won't get plated through holes, so you have to
wire through all vias.

The commercial places are, as far as I know, reasonably priced
for what they do.

-- glen

Article: 157516
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 17:11:10 -0800 (PST)
Links: << >>  << T >>  << A >>
Version 2.0. Much faster, cleaner:

   http://m.youtube.com/watch?v=uIIwU29H3E8

Best regards,
Rick C. Hodgin

Article: 157517
Subject: Re: Using FPGA to feed 80386
From: chrisabele <ccabele@yahoo.com>
Date: Sun, 14 Dec 2014 21:32:52 -0500
Links: << >>  << T >>  << A >>
On 12/14/2014 6:56 PM, rickman wrote:
> On 12/14/2014 1:47 PM, Rick C. Hodgin wrote:
>> How would I go about making my own boards?
>> I am aware of commercial companies which
>> have software you can download, and construct
>> the layout through their process manufacturing,
>> and you will receive boards and solder masks.
>>
>> But are there things you can do yourself? Buy a
>> blank copper layer, cover with a photoresist,
>> expose a mask, and then chemically etch away
>> the exposed or unexposed are (depending on
>> the resist)?
>
> I don't bother with that anymore.  I think I made one or two PCBs back
> in my misspent youth though.  It is a messy, somewhat complex and
> unrewarding task to make crude PCBs yourself and then you have corrosive
> chemicals to dispose of.  Even assembly of PCBs is a PITA in my opinion
> although I will do a little work on them.  But this is my perspective
> where my eyes and hands are nowhere near as good as they used to be even
> if my patience is a lot better.
>
> I much prefer to let contract assembly houses do my dirty work for me.
> PCBs can be downright cheap if you limit them to 4 layers.  There are a
> number of places which will batch numerous user's boards to make panels
> (the size that the PCB fabricator produces) and then ship everyone their
> individual boards.  Oshpark is one I have seen a lot of.  ITEAD provides
> a similar service and will also do the assembly.  Then I just read about
> dirtypcbs.com who also make cheap PCBs.
>
> FPGAs are easy because you can test your code in a simulator and reload
> in the hardware anything that doesn't work.  Actual hardware is not so
> easy and mistakes can get expensive.  You need to start small and work
> your way up.  Laying out a board has a *lot* of pitfalls.  With a $50 to
> $100 worth of parts on the board you don't want to mess it up too many
> times.
>
Listen to Rick: don't try to make your own boards.

I don't have the kind of professional board layout experience that many 
of the regular contributors here do, but I've played around at the 
experimenter level for many years. I have etched my own boards (very 
many years ago) and I don't recommend it. There are many way to mess it 
up, and even if you do everything perfectly you'll only produce a crude 
board. I haven't used the places Rick mentioned, but I've had good 
results from Alberta Printed Circuits (http://www.apcircuits.com/).

Regardless of how you get the board made, you'll need to design it 
first. There are lots of inexpensive (even free) CAD tools available and 
I'm sure you can get good recommendations here. You'll need to create a 
schematic as the first step in designing a PC board, even if you use an 
integrated suite those will generally be separate tools.

And finally I'm not quite clear: are you honestly considering designing 
and building a custom board for your project, or are you just curious 
about the process and the step involved? What's your experience 
designing and building hardware previously?



Article: 157518
Subject: Re: Using FPGA to feed 80386
From: hamilton <hamilton@nothere.com>
Date: Sun, 14 Dec 2014 19:33:11 -0700
Links: << >>  << T >>  << A >>
On 12/14/2014 6:11 PM, Rick C. Hodgin wrote:
> Version 2.0. Much faster, cleaner:
>
>     http://m.youtube.com/watch?v=uIIwU29H3E8
>
> Best regards,
> Rick C. Hodgin
>

LOL, did you notice that the PCB is white and not green ??

What to know why ??

hamilton

Article: 157519
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 18:35:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Why couldn't this kind of mod be used with the
previous video's 450nm 90mA laser diode to
combine into a single system? If you set the
printer for highest resolution, and use staggered
laser diodes and a buffer circuit, you could
accumulate the print signals for each row, and then on the next row print them as it passes by
while accumulating that row's data.

It would only require always making sure you
print an extra little bit so the last real row isn't
invalidated by the eject.

   http://m.youtube.com/watch?v=Fpflg2KcORY

Best regards,
Rick C. Hodgin

Article: 157520
Subject: Re: Using FPGA to feed 80386
From: rickman <gnuarm@gmail.com>
Date: Sun, 14 Dec 2014 22:36:05 -0500
Links: << >>  << T >>  << A >>
On 12/14/2014 7:03 PM, Rick C. Hodgin wrote:
> I found this video. It was interesting. Also some
> instructables on the process.
>
>      http://www.youtube.com/watch?v=tWnfnt2rNO0

It is not hard to make your own single sided PCBs for DIP packages and 
the larger pitch leaded surface mount parts.  But if you try to do 
anything beyond that you will find it is quite an effort.

Etching is not the hard part.  How do you connect traces through vias on 
double sided boards?  Even trying to do finer pitch parts on single 
sided boards is hard because there is no solder resist and shorts are 
very hard to prevent.

Remember, this video was an ad by Jameco.

-- 

Rick

Article: 157521
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 19:50:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Rickman wrote:
> How do you connect traces through vias on
> double sided boards?

The solution is obvious: solder material cast
into rivets, with a special tool for automated
insertion and mechanical compression, with
even an optional heated welding as by a
separate lower power laser step.

Also, there's no reason a device couldn't be
constructed to laser etch both sides at the same
time, even post-processong for burn-thrus in
liew of mechanical drilling. Use of staggered
lasers would also allow faster throughput.

I think there's a business opportunity here.

Best regards,
Rick C. Hodgin

Article: 157522
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 19:59:14 -0800 (PST)
Links: << >>  << T >>  << A >>
Rickman wrote:
> ...because there is no solder resist and shorts
> are very hard to prevent.

A simultaneous parallel laser could burn thru
a transparency to provide the solder mask.

An assembly line could even be created to run
them N-off in assembled form. Automated
deposition of solder paste, physical IC packages,
run through an oven, cooldown and testing.

It could all be done in a year from idea to
production.

Best regards,
Rick C. Hodgin

Article: 157523
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 20:01:35 -0800 (PST)
Links: << >>  << T >>  << A >>
crisabele wrote:
> What's your experience designing and
> building hardware previously?

Minimal. Nearly zero with regards to ICs, and
zero related to FPGAs.

Best regards,
Rick C. Hodgin

Article: 157524
Subject: Re: Using FPGA to feed 80386
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sun, 14 Dec 2014 20:25:24 -0800 (PST)
Links: << >>  << T >>  << A >>
I found these chips available for $10 each. 3.3V
fully static, 16-bit data bus.

    http://www.findchips.com/search/ng80386sxl-33

I am considering them.

Best regards,
Rick C. Hodgin



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