Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Ads

Discussion Groups

Discussion Groups | FPGA-CPU | Re: Re: why FPGA?

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

Re: Re: why FPGA? - Jeff Brower - Jan 10 14:04:00 2005

Rick-

> > I'm just a litlle bit curious. Why did you choose an FPGA device
> > instead of a normal micro? Do you have some very unusual hardware
> > need? And further, do you have space for both CPU and your hardware
> > in the FPGA?
> > Can you tell us about your CPU design? (How many bits are your
> > stacks, instr. length etc.). This is very interesting.
>
> Sure, I can tell you about it; first the why. I started with a design
> for a DSP with various memory and a latest technology main FPGA that
> is not 5 volt tolerant. I needed to add a low power processor to boot
> the board from Flash and a second FPGA to provide a 5 volt tolerant
> interface to an external bus.

1) S-III can be made 5-V tolerant with 220 series Rs to PCI bus. Xilinx has a page
on this.

2) For very low-power / tight board space application, why not boot the DSP from
Flash, then boot the FPGA? This avoids the logic PROM and makes logic and code
upgrade a standardized process.

-Jeff > Originally, I thought of using one of the small 8 bit MCUs to boot the
> second FPGA from a Flash chip. But as these get large enough to do
> all the tasks (mainly the IO count) they get more expensive. I then
> found that I could add one of the newer ARM MCUs for about the same
> price. But some of the MCU functions could not be done with the ARM
> because it needed to be automotive temperature.
>
> Much thinking and looking at data sheets later, I realized that this
> would still require a small 8 bit MCU to do the temperature
> measurement, manage the real time clock and control the reset/power on
> sequence of the board. That in turn made the ARM pointless if I moved
> the workhorse processor onto the FPGA.
>
> So the current design uses a small, very low power, very inexpensive 8
> bit MCU (haven't picked it yet, but PIC and PSOC are stong contenders)
> to do the most basic power on type functions with the aid of an RTC
> chip (finally found an automotive temp one). Using a NAND flash (much
> fewer IOs needed because of no address bus), it will boot the FPGA
> with an internal CPU to do all the data movement functions. I wanted
> to program all this in Forth and so I designed it as a stack processor.
>
> The stack CPU is not exactly the Forth VM, but it is a bit similar to
> some of the CPUs that Chuck Moore has designed. I borrowed ideas from
> his work, the Transputer and a few other places and wrapped it all up
> in a design that is targeted at keeping the instruction set efficiency
> high due to the limited size of the on chip FPGA memory.
>
> So there it is. This CPU uses 8 bit opcodes (I first tried 4 bit
> codes, but too many required opcode extensions to get anything done,
> and 5 or 6 did not map to the memory well) opimized for efficiency of
> calls and returns. This was decided after reading Philip Koopman's
> analysis of instruction frequencies (both static and dynamic) that
> these were the most important instructions to optimize.
>
> Also optimized were the jumps and literal construction (specifically
> address loading). To keep the machine simple, I tried to make every
> instruction a single clock cycle. More specifically, I designed every
> instruction so they would be a single clock cycle without a complex
> architecture.
>
> It ended up pretty small, about 600 LEs in an ACEX 1K family FPGA. It
> currently clocks at over 50 MHz. To compile it for more current
> FPGAs, I would have to change the memory from async to sync. This
> will make a read of memory two clocks instead of one, but not the
> stacks or the program fetch. I expect it will run at over 80 MHz in a
> Spartan 3 part (which it will when I get to that point).
>
> Is that enough info?
>
> I don't mind posting this here, but it might be more relevant in the
> fpga-cpu group. I'll also post this reply there.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )


Re: why FPGA? - Author Unknown - Jan 10 14:22:00 2005


Moved here from armForth group...

--- In , "raimond712002" <raimond@e...> wrote:
>
> Rick,
>
> I'm just a litlle bit curious. Why did you choose an FPGA device
> instead of a normal micro? Do you have some very unusual hardware
> need? And further, do you have space for both CPU and your hardware
> in the FPGA?
> Can you tell us about your CPU design? (How many bits are your
> stacks, instr. length etc.). This is very interesting.

Sure, I can tell you about it; first the why. I started with a design
for a DSP with various memory and a latest technology main FPGA that
is not 5 volt tolerant. I needed to add a low power processor to boot
the board from Flash and a second FPGA to provide a 5 volt tolerant
interface to an external bus.

Originally, I thought of using one of the small 8 bit MCUs to boot the
second FPGA from a Flash chip. But as these get large enough to do
all the tasks (mainly the IO count) they get more expensive. I then
found that I could add one of the newer ARM MCUs for about the same
price. But some of the MCU functions could not be done with the ARM
because it needed to be automotive temperature.

Much thinking and looking at data sheets later, I realized that this
would still require a small 8 bit MCU to do the temperature
measurement, manage the real time clock and control the reset/power on
sequence of the board. That in turn made the ARM pointless if I moved
the workhorse processor onto the FPGA.

So the current design uses a small, very low power, very inexpensive 8
bit MCU (haven't picked it yet, but PIC and PSOC are stong contenders)
to do the most basic power on type functions with the aid of an RTC
chip (finally found an automotive temp one). Using a NAND flash (much
fewer IOs needed because of no address bus), it will boot the FPGA
with an internal CPU to do all the data movement functions. I wanted
to program all this in Forth and so I designed it as a stack processor.

The stack CPU is not exactly the Forth VM, but it is a bit similar to
some of the CPUs that Chuck Moore has designed. I borrowed ideas from
his work, the Transputer and a few other places and wrapped it all up
in a design that is targeted at keeping the instruction set efficiency
high due to the limited size of the on chip FPGA memory.

So there it is. This CPU uses 8 bit opcodes (I first tried 4 bit
codes, but too many required opcode extensions to get anything done,
and 5 or 6 did not map to the memory well) opimized for efficiency of
calls and returns. This was decided after reading Philip Koopman's
analysis of instruction frequencies (both static and dynamic) that
these were the most important instructions to optimize.

Also optimized were the jumps and literal construction (specifically
address loading). To keep the machine simple, I tried to make every
instruction a single clock cycle. More specifically, I designed every
instruction so they would be a single clock cycle without a complex
architecture.

It ended up pretty small, about 600 LEs in an ACEX 1K family FPGA. It
currently clocks at over 50 MHz. To compile it for more current
FPGAs, I would have to change the memory from async to sync. This
will make a read of memory two clocks instead of one, but not the
stacks or the program fetch. I expect it will run at over 80 MHz in a
Spartan 3 part (which it will when I get to that point).

Is that enough info?

I don't mind posting this here, but it might be more relevant in the
fpga-cpu group. I'll also post this reply there.






(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: why FPGA? - Author Unknown - Jan 10 15:03:00 2005


--- In , Jeff Brower <jbrower@s...> wrote:
> Rick-
> 1) S-III can be made 5-V tolerant with 220 series Rs to PCI bus.
Xilinx has a page
> on this.

This is not really correct. I don't think you can drive a bus with a
220 ohm series resistor. The resistor trick is only useful for inputs. > 2) For very low-power / tight board space application, why not boot
the DSP from
> Flash, then boot the FPGA? This avoids the logic PROM and makes
logic and code
> upgrade a standardized process.

What controls when the DSP is booted? In reality it wouldn't save
anything. The board has ADCs to monitor the supply voltages and
measure temperature. It also requires some logic to combine several
sources of reset. Turns out that the most efficient way to do this is
in a small 8 bit MCU. I can get an MCU cheaper than a multichannel 10
bit ADC! And the MCU will be automotive temperature.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - Jeff Brower - Jan 10 15:17:00 2005

Rick-

> > 1) S-III can be made 5-V tolerant with 220 series Rs to PCI bus.
> Xilinx has a page
> > on this.
>
> This is not really correct. I don't think you can drive a bus with a
> 220 ohm series resistor. The resistor trick is only useful for inputs.

Yes I was talking about inputs. I was assuming the "5V tolerant" FPGA drives out at
3.3V and the system can accept that. If 5V out is required then level translation
switch or buffers (or something) is needed.

> What controls when the DSP is booted? In reality it wouldn't save
> anything. The board has ADCs to monitor the supply voltages and
> measure temperature. It also requires some logic to combine several
> sources of reset. Turns out that the most efficient way to do this is
> in a small 8 bit MCU. I can get an MCU cheaper than a multichannel 10
> bit ADC! And the MCU will be automotive temperature.

It sounds good. I was not factoring in temperature and just thinking a small RTC
connected to the DSP, then let the DSP boot and do everything else since it's
programmable.

-Jeff


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: why FPGA? - Author Unknown - Jan 10 16:51:00 2005


--- In , Jeff Brower <jbrower@s...> wrote:
> Rick-
>
> > > 1) S-III can be made 5-V tolerant with 220 series Rs to PCI bus.
> > Xilinx has a page
> > > on this.
> >
> > This is not really correct. I don't think you can drive a bus with a
> > 220 ohm series resistor. The resistor trick is only useful for
inputs.
>
> Yes I was talking about inputs. I was assuming the "5V tolerant"
FPGA drives out at
> 3.3V and the system can accept that. If 5V out is required then
level translation
> switch or buffers (or something) is needed.

It is not an issue of needing 5 volts out, the problem is that most
bus interfaces need bidirectional signals. It is not practical to use
a resistor to protect a pin when it also has to drive the signal.
Even if it is an output only, such as interrupt pins, if the signal is
pulled up to 5 volts, you have a problem.






(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - woodelf - Jan 10 17:00:00 2005

wrote:

>It is not an issue of needing 5 volts out, the problem is that most
>bus interfaces need bidirectional signals. It is not practical to use
>a resistor to protect a pin when it also has to drive the signal.
>Even if it is an output only, such as interrupt pins, if the signal is
>pulled up to 5 volts, you have a problem. Alot of things still use TTL logic levels. A IDE interface comes to mind.
Yet now days you have nice 3.3 volt memory out-there that is dieing to
used in a small cpu design. Ramton's 32kx8 Non-voilatile memory comes
to mind, but only the 3.3 volt version gives you unlimited read/write
cycles.
Also driving leds from 3.3 volt logic is not that easy too.




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - Kolja Sulimma - Jan 10 17:22:00 2005

woodelf wrote:

>Also driving leds from 3.3 volt logic is not that easy too. When I drive LEDs I use the logic to pull the output signal towards
ground and connect the other end to VCC.
You can do that in a spartan-3 with VCCIO=0.8V.

Kolja Sulimma




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - woodelf - Jan 10 17:26:00 2005

Kolja Sulimma wrote:

>When I drive LEDs I use the logic to pull the output signal towards
>ground and connect the other end to VCC.
>You can do that in a spartan-3 with VCCIO=0.8V. Everybody has the low output drive. The current limiting on the LED's is
the problem.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - Kolja Sulimma - Jan 10 17:35:00 2005

wrote:

>It is not an issue of needing 5 volts out, the problem is that most
>bus interfaces need bidirectional signals. It is not practical to use
>a resistor to protect a pin when it also has to drive the signal.
>
It is practical.

IIRC to protect a spartan-3 pin you need to limit the current to 10mA.
For PCI you need to be able to handle 7.1V overshoot so at 3.3V VCCIO
you would need 380R.
(Actually less, because of the voltage drop in the protection diodes,
but I do not remember the values)

This resistance value leaves you more than 8mA of output drive. This is
not enough to be PCI compliant but
a lot more than the outputs of many uC and a factor of four stronger
than the weakest FPGA pin configuration..

>Even if it is an output only, such as interrupt pins, if the signal is
>pulled up to 5 volts, you have a problem. If you pull the pin to 5V, but if you connect a 1k resistor to 5V to a
spartan-3 input it will only pull up to 3.5V or so
and continously draw 1.5mA of current through the protection diodes.
That't nothing the chip can't handle.

Kolja Sulimma


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - Kolja Sulimma - Jan 10 17:36:00 2005

woodelf wrote:

>Kolja Sulimma wrote: >
>>When I drive LEDs I use the logic to pull the output signal towards
>>ground and connect the other end to VCC.
>>You can do that in a spartan-3 with VCCIO=0.8V.
>>
>>
>>
>>
>Everybody has the low output drive. The current limiting on the LED's is
>the problem. But how does it become easier with a 5V device?

Kolja Sulimma


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - woodelf - Jan 10 17:50:00 2005

Kolja Sulimma wrote:

>But how does it become easier with a 5V device? You can have a current limiting resistor say about 300 ohms to drop about
2 volts. Check with the leds you with to drive for exact voltages needed.
Note with the current limiting resistor for dropping FPGA input levels watch
the R/C time constant.

>Kolja Sulimma





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Re: why FPGA? - Austin Franklin - Jan 10 18:08:00 2005

Hi woodelf,

> Alot of things still use TTL logic levels.

TTL is low of less than .8V and a high of greater than 2.2V. That works
fine with CMOS 3.3V, as CMOS is specified to drive %80 of the power rail.
This is fine for outputs.

For inputs, you either need to use a current limiting resistor, if the spec
you are interfacing to can tolerate it (PCI does not), or use QuickSwitches.

> Also driving leds from 3.3 volt logic is not that easy too.

How so? You need to select the appropriate LED.

Regards,

Austin




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

RE: Re: why FPGA? - Austin Franklin - Jan 10 18:10:00 2005

Jeff,

> 1) S-III can be made 5-V tolerant with 220 series Rs to PCI bus.
> Xilinx has a page
> on this.

I believe that is not PCI compliant using a simple resistor, unless you are
in a fully embedded application, where it really doesn't matter what you do,
as long as you can control everything...which you can not do in a plug-in
card. In that case, the preference is to use QuickSwitches.

Regards,

Austin




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: why FPGA? - Author Unknown - Jan 10 20:43:00 2005


--- In , Kolja Sulimma <kolja@s...> wrote:
> dsprelated@a... wrote:
>
> >It is not an issue of needing 5 volts out, the problem is that most
> >bus interfaces need bidirectional signals. It is not practical to use
> >a resistor to protect a pin when it also has to drive the signal.
> >
> It is practical.
>
> IIRC to protect a spartan-3 pin you need to limit the current to 10mA.
> For PCI you need to be able to handle 7.1V overshoot so at 3.3V VCCIO
> you would need 380R.
> (Actually less, because of the voltage drop in the protection diodes,
> but I do not remember the values)
>
> This resistance value leaves you more than 8mA of output drive. This is
> not enough to be PCI compliant but
> a lot more than the outputs of many uC and a factor of four stronger
> than the weakest FPGA pin configuration..

Yes, this is not enough to be PCI compliant, it is not enough to drive
a fast signal on any bus. Most importantly, it is not just the *max*
current that is limited, the slew rate is slowed considerably because
the current during the entire ramp up time is reduced.

Sure, there are applications where the reduced drive is not a problem.
But in general, the greatly slowed edge rate limits performance
greatly. > >Even if it is an output only, such as interrupt pins, if the signal is
> >pulled up to 5 volts, you have a problem.
> >
> >
> If you pull the pin to 5V, but if you connect a 1k resistor to 5V to a
> spartan-3 input it will only pull up to 3.5V or so
> and continously draw 1.5mA of current through the protection diodes.
> That't nothing the chip can't handle.

I'm not talking about protecting the chip. I am saying that with a
470 ohm pullup, you can only pull the signal down to about 2 volts
with at 220 ohm resistor in series with the IO pin. The PC ISA bus
has several of these. Even with a 1k pullup you only get down to
about a volt.

The limiting resistor always protects the chip, but it can interfere
with what the chip is doing.





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Re: why FPGA? - Kolja Sulimma - Jan 11 3:09:00 2005

woodelf wrote:

>Kolja Sulimma wrote: >
>>But how does it become easier with a 5V device?
>>
>>
>>
>>
>You can have a current limiting resistor say about 300 ohms to drop about
>2 volts. Check with the leds you with to drive for exact voltages needed. You can do that with any voltage above the voltage drop of the LED.
An LED will drop 1.7V (depends on the color). If you want to drive it
with a current of I the resistor needed is
R = (VCC-1.7V)/I

>Note with the current limiting resistor for dropping FPGA input levels watch
>the R/C time constant. With a CMOS output you have an IC time constant, with a resistor you
have an RC constant, the difference
does not matter at all. I do not care whether my output slopes are
exponential or linear.
The fujitsu microcontroller on my desk will drive the outputs with about
4mA.
An FPGA with 380R on its output can have slopes about twice as fast.
Thats not enough for PCI, but it is close
to default settting of the FPGA outputs without resistor so it can't be
that bad.

Kolja Sulimma



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )