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
2019JanFebMar2019

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 158825

Article: 158825
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 21 Apr 2016 20:34:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> [snip]

Watch the videos, Rick.

Best regards,
Rick C. Hodgin

Article: 158826
Subject: Challenges in data science which can be solved with FPGAs
From: Prasad Pandit <prasadp4009@gmail.com>
Date: Sat, 23 Apr 2016 01:08:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Everyone,

I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs.

Article: 158827
Subject: Re: Challenges in data science which can be solved with FPGAs
From: Evgeny Filatov <filatov.ev@mipt.ru>
Date: Sat, 23 Apr 2016 17:33:41 +0300
Links: << >>  << T >>  << A >>
On 23.04.2016 11:08, Prasad Pandit wrote:
> Hi Everyone,
>
> I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs.
>

Hi. I want to know what are the challenges in agriculture which are 
being faced today and can be solved with a shovel.

Gene


Article: 158828
Subject: Re: Challenges in data science which can be solved with FPGAs
From: David Wade <dave.g4ugm@gmail.com>
Date: Sat, 23 Apr 2016 19:17:19 +0100
Links: << >>  << T >>  << A >>
On 23/04/2016 09:08, Prasad Pandit wrote:
> Hi Everyone,
>
> I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs.
>
Sounds like a homework question to me, i.e. I have been asked to write 
about/prepare a presentation on FPGA's in Data Science and Cloud Computing.

Rather than try and get us to do all the work why not google it and if 
there are things in the results you do not understand, or applications 
you think are missing, then come and ask about them.

Of course of you read the marketing then the FPGA is the answer to every 
question...


Dave

Article: 158829
Subject: Simplistic AXI4-Lite to IPbus bridge
From: wzab01@gmail.com
Date: Sun, 24 Apr 2016 13:29:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I found it useful to be able to control my IPbus ( https://svnweb.cern.ch/trac/cactus ) connected logic from an AXI4 master.
It may be used e.g. for testing or for porting the design to the ARM equipped FPGA (Zynq of Cyclone 5?). Of course in the latter case the next step should be writing an IPbus Control Hub for ARM, working as the AXI master...

At the moment I have written a very simple bridge, allowing you to control your IPbus compatible logic from an AXI master.

As AXI uses the byte addresses and IPbus uses word addresses, the AXI address is shifted right by 2 bits (divided by 4).
As IPbus does not support single byte accesses, the bridge allows only accesses to the whole word (you'll get bus error if you try to access a single byte, two or three bytes in the word).

This implementation wraps your IPbus controlled logic as "slaves" entity.
Of course if it has additional ports except of the IPbus, you must add necessary ports in the axil2ipb entity and connect them.

This is a first attempt to write such a bridge. It has not been tested very thoroughly, so don't be surprised if something works incorrectly.
You use it on your own risk!
This is a PUBLIC DOMAIN code (according to Creative Commons CC0 license) so it is published without any warranty.

(Anyway I hope, that somebody may found it useful).

The sources may be found at https://svnweb.cern.ch/trac/cactus/ticket/1876
or on the alt.sources group: https://groups.google.com/forum/#!topic/alt.sources/b2DpVU4A5Yo

With best regards,
Wojtek

Article: 158830
Subject: Deep Embedded Processor Board
From: rickman <gnuarm@gmail.com>
Date: Mon, 25 Apr 2016 12:49:11 -0400
Links: << >>  << T >>  << A >>
The thread on spinning a 386 in an FPGA made me think about the FPGA 
boards available.  I know you can find boards that are inexpensive and 
you can find FPGA boards that have support for processor oriented 
devices like RAM, Flash, Ethernet, etc.  But is there any overlap 
between these requirements?

I figured it should be practical to produce a board with SDRAM, a NAND 
Flash chip and the minimum interface needed for a few interfaces, 
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can 
envision could be prototyped in the FPGA and communicate with the real 
world.

Does this board exist?

-- 

Rick

Article: 158831
Subject: Re: Deep Embedded Processor Board
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 25 Apr 2016 19:14:22 +0100 (BST)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> I figured it should be practical to produce a board with SDRAM, a NAND 
> Flash chip and the minimum interface needed for a few interfaces, 
> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can 
> envision could be prototyped in the FPGA and communicate with the real 
> world.

This is something I'm doing at the moment.  We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined by
cache-coherent bridges.  On the ARM side are various hard peripherals (micro
SD, 1G ethernet, USB, DDR3).  It's possible to configure the bridges so that
the FPGA can look over the wall at the ARM-side peripherals, and so the FPGA
can map ARM-side peripherals into its own Avalon/AXI memory space.

This is more efficient than external chips, because there are not many
external chips for driving these kinds of embedded interfaces (most
separate-package USB/SD/SATA controllers would speak PCIe, which isn't what
you want)

However, once you have that setup you probably want to run the driver stack
on ARM Linux (drivers for things like USB being a pain, see our previous
conversation) and provide a more abstract interface to the FPGA - for
example a simple block device rather than dealing with the Synopsys USB
controller and USB mass storage.  Then you can get away with a much more
minimal software overhead on the FPGA. 

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the FPGA
isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, so
you can access the peripherals from either side.  But there's no cheap Arria
10 as yet.  There are also no Stratix IV/V parts with ARMs on them.

I don't know if Zynq can do something similar - anyone have more experience
with Xilinx-land?

Theo

Article: 158832
Subject: Re: Deep Embedded Processor Board
From: Allan Herriman <allanherriman@hotmail.com>
Date: 25 Apr 2016 22:27:26 GMT
Links: << >>  << T >>  << A >>
On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:

> rickman <gnuarm@gmail.com> wrote:
>> I figured it should be practical to produce a board with SDRAM, a NAND
>> Flash chip and the minimum interface needed for a few interfaces,
>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
>> envision could be prototyped in the FPGA and communicate with the real
>> world.
> 
> This is something I'm doing at the moment.  We do have a (somewhat
> heavyweight) processor which is constrained by its I/O.
> 
> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
> by cache-coherent bridges.  On the ARM side are various hard peripherals
> (micro SD, 1G ethernet, USB, DDR3).  It's possible to configure the
> bridges so that the FPGA can look over the wall at the ARM-side
> peripherals, and so the FPGA can map ARM-side peripherals into its own
> Avalon/AXI memory space.
> 
> This is more efficient than external chips, because there are not many
> external chips for driving these kinds of embedded interfaces (most
> separate-package USB/SD/SATA controllers would speak PCIe, which isn't
> what you want)
> 
> However, once you have that setup you probably want to run the driver
> stack on ARM Linux (drivers for things like USB being a pain, see our
> previous conversation) and provide a more abstract interface to the FPGA
> - for example a simple block device rather than dealing with the
> Synopsys USB controller and USB mass storage.  Then you can get away
> with a much more minimal software overhead on the FPGA.
> 
> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
> FPGA isn't very big:
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?
Language=English&CategoryNo=167&No=941
> 
> On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
> so you can access the peripherals from either side.  But there's no
> cheap Arria 10 as yet.  There are also no Stratix IV/V parts with ARMs
> on them.
> 
> I don't know if Zynq can do something similar - anyone have more
> experience with Xilinx-land?

Here's one in a familiar form factor at about the same price:
<http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html>

It has some odd design decisions though - the Ethernet goes through
a USB to Ethernet adapter, rather than using the native controller.
(I guess one can take the "Pi-compatibility" thing too seriously.)

Regards,
Allan

Article: 158833
Subject: Re: Deep Embedded Processor Board
From: rickman <gnuarm@gmail.com>
Date: Mon, 25 Apr 2016 21:18:18 -0400
Links: << >>  << T >>  << A >>
On 4/25/2016 6:27 PM, Allan Herriman wrote:
> On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:
>
>> rickman <gnuarm@gmail.com> wrote:
>>> I figured it should be practical to produce a board with SDRAM, a NAND
>>> Flash chip and the minimum interface needed for a few interfaces,
>>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
>>> envision could be prototyped in the FPGA and communicate with the real
>>> world.
>>
>> This is something I'm doing at the moment.  We do have a (somewhat
>> heavyweight) processor which is constrained by its I/O.
>>
>> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
>> by cache-coherent bridges.  On the ARM side are various hard peripherals
>> (micro SD, 1G ethernet, USB, DDR3).  It's possible to configure the
>> bridges so that the FPGA can look over the wall at the ARM-side
>> peripherals, and so the FPGA can map ARM-side peripherals into its own
>> Avalon/AXI memory space.
>>
>> This is more efficient than external chips, because there are not many
>> external chips for driving these kinds of embedded interfaces (most
>> separate-package USB/SD/SATA controllers would speak PCIe, which isn't
>> what you want)
>>
>> However, once you have that setup you probably want to run the driver
>> stack on ARM Linux (drivers for things like USB being a pain, see our
>> previous conversation) and provide a more abstract interface to the FPGA
>> - for example a simple block device rather than dealing with the
>> Synopsys USB controller and USB mass storage.  Then you can get away
>> with a much more minimal software overhead on the FPGA.
>>
>> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
>> FPGA isn't very big:
>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?
> Language=English&CategoryNo=167&No=941
>>
>> On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
>> so you can access the peripherals from either side.  But there's no
>> cheap Arria 10 as yet.  There are also no Stratix IV/V parts with ARMs
>> on them.
>>
>> I don't know if Zynq can do something similar - anyone have more
>> experience with Xilinx-land?
>
> Here's one in a familiar form factor at about the same price:
> <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html>
>
> It has some odd design decisions though - the Ethernet goes through
> a USB to Ethernet adapter, rather than using the native controller.
> (I guess one can take the "Pi-compatibility" thing too seriously.)

Interesting board.  That is an odd decision though.  Won't the kernel 
need to be recompiled for this compared to the rPi?  So why worry with 
making the Ethernet driver compatible?

-- 

Rick C

Article: 158834
Subject: Re: Deep Embedded Processor Board
From: Allan Herriman <allanherriman@hotmail.com>
Date: 26 Apr 2016 10:57:34 GMT
Links: << >>  << T >>  << A >>
On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote:

> On 4/25/2016 6:27 PM, Allan Herriman wrote:
>> On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:
>>
>>> rickman <gnuarm@gmail.com> wrote:
>>>> I figured it should be practical to produce a board with SDRAM, a 
NAND
>>>> Flash chip and the minimum interface needed for a few interfaces,
>>>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
>>>> envision could be prototyped in the FPGA and communicate with the 
real
>>>> world.
>>>
>>> This is something I'm doing at the moment.  We do have a (somewhat
>>> heavyweight) processor which is constrained by its I/O.
>>>
>>> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
>>> by cache-coherent bridges.  On the ARM side are various hard 
peripherals
>>> (micro SD, 1G ethernet, USB, DDR3).  It's possible to configure the
>>> bridges so that the FPGA can look over the wall at the ARM-side
>>> peripherals, and so the FPGA can map ARM-side peripherals into its own
>>> Avalon/AXI memory space.
>>>
>>> This is more efficient than external chips, because there are not many
>>> external chips for driving these kinds of embedded interfaces (most
>>> separate-package USB/SD/SATA controllers would speak PCIe, which isn't
>>> what you want)
>>>
>>> However, once you have that setup you probably want to run the driver
>>> stack on ARM Linux (drivers for things like USB being a pain, see our
>>> previous conversation) and provide a more abstract interface to the 
FPGA
>>> - for example a simple block device rather than dealing with the
>>> Synopsys USB controller and USB mass storage.  Then you can get away
>>> with a much more minimal software overhead on the FPGA.
>>>
>>> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
>>> FPGA isn't very big:
>>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?
>> Language=English&CategoryNo=167&No=941
>>>
>>> On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
>>> so you can access the peripherals from either side.  But there's no
>>> cheap Arria 10 as yet.  There are also no Stratix IV/V parts with ARMs
>>> on them.
>>>
>>> I don't know if Zynq can do something similar - anyone have more
>>> experience with Xilinx-land?
>>
>> Here's one in a familiar form factor at about the same price:
>> <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/
te0726-zynq.html>
>>
>> It has some odd design decisions though - the Ethernet goes through
>> a USB to Ethernet adapter, rather than using the native controller.
>> (I guess one can take the "Pi-compatibility" thing too seriously.)
> 
> Interesting board.  That is an odd decision though.  Won't the kernel 
> need to be recompiled for this compared to the rPi?  So why worry with 
> making the Ethernet driver compatible?

I was joking about the Pi compatibility.  I don't expect that this board 
would be running a distro like Raspbian.

It's hard to know the designer's intent.  For all I know, he chose to 
forgo the native Gb Ethernet interface because there wasn't enough room 
for a PHY (and its power supply), although looking at the block diagram, 
it seems more likely that he wanted to reserve the pins for GPIOs (I 
assume the 53 MIO pins are shared between the bootflash, USB, UART, SDCard 
and the GPIO).

Regards,
Allan

Article: 158835
Subject: Re: Deep Embedded Processor Board
From: Allan Herriman <allanherriman@hotmail.com>
Date: 26 Apr 2016 11:40:23 GMT
Links: << >>  << T >>  << A >>
On Tue, 26 Apr 2016 10:57:34 +0000, Allan Herriman wrote:

> On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote:
> 
>> On 4/25/2016 6:27 PM, Allan Herriman wrote:
>>> On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:
>>>
>>>> rickman <gnuarm@gmail.com> wrote:
>>>>> I figured it should be practical to produce a board with SDRAM, a
> NAND
>>>>> Flash chip and the minimum interface needed for a few interfaces,
>>>>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
>>>>> envision could be prototyped in the FPGA and communicate with the
> real
>>>>> world.
>>>>
>>>> This is something I'm doing at the moment.  We do have a (somewhat
>>>> heavyweight) processor which is constrained by its I/O.
>>>>
>>>> Altera's Cyclone V SoC parts have an ARM side and an FPGA side,
>>>> joined by cache-coherent bridges.  On the ARM side are various hard
> peripherals
>>>> (micro SD, 1G ethernet, USB, DDR3).  It's possible to configure the
>>>> bridges so that the FPGA can look over the wall at the ARM-side
>>>> peripherals, and so the FPGA can map ARM-side peripherals into its
>>>> own Avalon/AXI memory space.
>>>>
>>>> This is more efficient than external chips, because there are not
>>>> many external chips for driving these kinds of embedded interfaces
>>>> (most separate-package USB/SD/SATA controllers would speak PCIe,
>>>> which isn't what you want)
>>>>
>>>> However, once you have that setup you probably want to run the driver
>>>> stack on ARM Linux (drivers for things like USB being a pain, see our
>>>> previous conversation) and provide a more abstract interface to the
> FPGA
>>>> - for example a simple block device rather than dealing with the
>>>> Synopsys USB controller and USB mass storage.  Then you can get away
>>>> with a much more minimal software overhead on the FPGA.
>>>>
>>>> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
>>>> FPGA isn't very big:
>>>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?
>>> Language=English&CategoryNo=167&No=941
>>>>
>>>> On the Arria 10 (and Stratix 10) the ARM and FPGA are more
>>>> integrated,
>>>> so you can access the peripherals from either side.  But there's no
>>>> cheap Arria 10 as yet.  There are also no Stratix IV/V parts with
>>>> ARMs on them.
>>>>
>>>> I don't know if Zynq can do something similar - anyone have more
>>>> experience with Xilinx-land?
>>>
>>> Here's one in a familiar form factor at about the same price:
>>> <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/
> te0726-zynq.html>
>>>
>>> It has some odd design decisions though - the Ethernet goes through a
>>> USB to Ethernet adapter, rather than using the native controller. (I
>>> guess one can take the "Pi-compatibility" thing too seriously.)
>> 
>> Interesting board.  That is an odd decision though.  Won't the kernel
>> need to be recompiled for this compared to the rPi?  So why worry with
>> making the Ethernet driver compatible?
> 
> I was joking about the Pi compatibility.  I don't expect that this board
> would be running a distro like Raspbian.
> 
> It's hard to know the designer's intent.  For all I know, he chose to
> forgo the native Gb Ethernet interface because there wasn't enough room
> for a PHY (and its power supply), although looking at the block diagram,
> it seems more likely that he wanted to reserve the pins for GPIOs (I
> assume the 53 MIO pins are shared between the bootflash, USB, UART,
> SDCard and the GPIO).


I should have looked at the schematic instead of the block diagram.  The 
GPIOs are connected to Bank 34 (on the PL, not the PS), and the 53 MIO 
pins on the PS are used for I2C, USB, SDCard, QSPI (bootflash) and some 
GPIO connected to a MACHX02 CPLD.
It seems the designer simply ran out of MIO pins and wasn't able to fit 
in Ethernet (although this could have been run through the EMIO to PL 
pins).

On Zynq designs of mine, I've managed to fit in USB, bootflash, SDCard, 
Ethernet, UARTs, I2C and some GPIO on the MIO, and a second Ethernet port 
via EMIO and PL pins.

Regards,
Allan

Article: 158836
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 26 Apr 2016 07:11:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, April 16, 2016 at 11:31:21 AM UTC-4, Herbert Kleebauer wrote:
> On 16.04.2016 16:58, Rick C. Hodgin wrote:
> > On Tuesday, April 5, 2016 at 3:15:38 PM UTC-4, Rick C. Hodgin wrote:
> >> I have a desire to create an 80386 CPU in FPGA form, one which will plug in
> >> to the 132-pin socket of existing 80386 motherboard as a replacement CPU. 
> > Does anyone have one of these types boards on their shelf from back in
> > the day?
> 
> http://www.forcetechnologies.co.uk/news/replacement-for-intel-processors-in-high-reliability-long-life-systems
> http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation

I have been in contact with Amanda from their sales department.  They are
unwilling to sell me a single board with hardware interface because I am
not a company, and do not / will not have volume throughput.  However, I
have also found out they sell a Soft x86 IP Core which is for Altera FPGAs,
so I am finding out if they will sell me a copy of that core or not, and
how much it costs.

Now, off to pray... :-)

Best regards,
Rick C. Hodgin

Article: 158837
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Herbert Kleebauer <klee@unibwm.de>
Date: Tue, 26 Apr 2016 18:54:35 +0200
Links: << >>  << T >>  << A >>
On 26.04.2016 16:11, Rick C. Hodgin wrote:

>> http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation
> 
> I have been in contact with Amanda from their sales department.  They are
> unwilling to sell me a single board with hardware interface because I am
> not a company, and do not / will not have volume throughput. 

Why don't you tell them that you maybe will order 10k boards, but
first you need a free demo board.

> Now, off to pray... :-)

That doesn't help. Don't pray but lie if you want a board.




Article: 158838
Subject: Re: Challenges in data science which can be solved with FPGAs
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Thu, 28 Apr 2016 20:22:48 +0200
Links: << >>  << T >>  << A >>
Prasad Pandit <prasadp4009@gmail.com> writes:


> I want to know what are the challenges in data science and cloud
> computing which are being faced today and can be solved with FPGAs.

The main challenge with respect to FPGA/ASIC in data science and machine
learning today is to fight the misconception that solving the problem
require a GPU and floating point support.

//Petter

-- 
.sig removed by request. 

Article: 158839
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sun, 1 May 2016 18:24:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Sorry for the long latency guys, I don't have much time in the day for 
myself, so Usenet often suffers. :)

On Sat, 09 Apr 2016 10:42:23 -0400, rickman wrote:

> On 4/9/2016 6:00 AM, Aleksandar Kuktin wrote:
>> On Wed, 06 Apr 2016 13:38:19 -0700, Rick C. Hodgin wrote:

>> I designed and implemented a 16-bit soft CPU from scratch, and I can
>> tell you it's seriously difficult to make it work. Right now, I'm
>> hacking a 32-
>> bit CPU (aeMB, to be very specific) and interfacing it to a SoC I plan
>> to publish eventually and again, it's seriously difficult to make it
>> work.
> 
> I'm surprised that you say it is hard to make it work.  Do you mean it
> is hard to build all the infrastructure?  I have designed my own CPUs
> before and found that part easy.  It is creating the software support
> that is hard, or at least a lot of work.  I use Forth which helps make
> things easier.

I find difficulty in producing a design that is simultaneously low-
latency, high speed and feature-full. To obtain low latency, you really 
can't use registers as much as you would like, and instead have to shift 
a lot of the logic into gates (pure asynchronous logic). However, if you 
do that, you quickly add up a too long chain of gates that can not be run 
at high clock rates. Finally, if you get both of these, you probably 
won't have enough wiggle room left over for features.

Right now, with what I'm currently working on, I have a blessing in that 
I don't have to run the circuit very fast so I can get away with three-
gate deep logic, maybe even four gate deep. But if I were going for break-
neck speeds, I would be constrained to logic two LUT4 gates deep. Only so 
many features can be crammed into a design made with that. :)

>> If you add a bit to the word or address size, you are not just doubling
>> the CPUs capabilities, you are also doubling the number, size and scope
>> of problems you have to deal with.
> 
> ???  My CPU design did not specify the data size, only the instruction
> size.  I didn't have a problem adjusting the data size to suit my
> application.

I suppose you can parameterize the data size, and later change the 
definition of the parameter to suit.

The problem - for me - is the underlying result which still needs to fit 
in the real world. This may have something to do with the way I cram as 
much "stuff" into a chip as I can. It was only here that I learned you 
should consider your chip "full" when it start reaching 80% utilization. 
For me, over 95% is common.

Adding a single bit to a round number can throw the synthesis results way 
out of optimum. Adding one more can make the gate chain too long to fit 
into a clock cycle. Changing the clock period can be impossible because 
the design could have several other interlocking clocks. And on and on. 

For example - I discovered that the synthesis tool I used (Lattices 
synthesizer) would produce a sub-optimal result if a unit - say a module 
- had even a single odd-sized register. Changing the register sizes to 
even numbers makes synthesis much better, even if it does throw away a 
bit.

>>>> Does simulation count? :D
>>>
>>> Yes.  Also in emulation, as by a real FPGA product, but one which does
>>> not plug into a socket, but is its own entire creation.  Here's an
>>> Aleksander who created a 486 SX CPU (it has not integrated FPU):
>>>
>>>      https://github.com/alfikpl/ao486
>>
>> Verily, I shall review this. I'm starting to get the impression that
>> all the stuff I'm making on my own has already been solved, but hasn't
>> been advertised. I'm working on my dream computer, but these solved
>> systems constantly keep popping up. Maybe all of it has already been
>> solved?
> 
> Exactly what is your dream computer?

A device whose design can fit in my head, that is transparent and 
serviceable on all levels, free(-as-in-freedom), secure and usable for 
real-world tasks. I should probably put "usable" at the top of the 
list. :)

Right now, that would mean a FPGA-implemented FOSH SoC that is self-
contained. That means, which can regenerate the images and binaries of 
itself, by itself (so you don't need a second computer for that).

Article: 158840
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Sun, 1 May 2016 23:13:44 -0400
Links: << >>  << T >>  << A >>
On 5/1/2016 2:24 PM, Aleksandar Kuktin wrote:
> Sorry for the long latency guys, I don't have much time in the day for
> myself, so Usenet often suffers. :)
>
> On Sat, 09 Apr 2016 10:42:23 -0400, rickman wrote:
>
>> On 4/9/2016 6:00 AM, Aleksandar Kuktin wrote:
>>> On Wed, 06 Apr 2016 13:38:19 -0700, Rick C. Hodgin wrote:
>
>>> I designed and implemented a 16-bit soft CPU from scratch, and I can
>>> tell you it's seriously difficult to make it work. Right now, I'm
>>> hacking a 32-
>>> bit CPU (aeMB, to be very specific) and interfacing it to a SoC I plan
>>> to publish eventually and again, it's seriously difficult to make it
>>> work.
>>
>> I'm surprised that you say it is hard to make it work.  Do you mean it
>> is hard to build all the infrastructure?  I have designed my own CPUs
>> before and found that part easy.  It is creating the software support
>> that is hard, or at least a lot of work.  I use Forth which helps make
>> things easier.
>
> I find difficulty in producing a design that is simultaneously low-
> latency, high speed and feature-full. To obtain low latency, you really
> can't use registers as much as you would like, and instead have to shift
> a lot of the logic into gates (pure asynchronous logic). However, if you
> do that, you quickly add up a too long chain of gates that can not be run
> at high clock rates. Finally, if you get both of these, you probably
> won't have enough wiggle room left over for features.
>
> Right now, with what I'm currently working on, I have a blessing in that
> I don't have to run the circuit very fast so I can get away with three-
> gate deep logic, maybe even four gate deep. But if I were going for break-
> neck speeds, I would be constrained to logic two LUT4 gates deep. Only so
> many features can be crammed into a design made with that. :)

Maybe I don't know what you mean by fast and not fast.  Got some numbers?


>>> If you add a bit to the word or address size, you are not just doubling
>>> the CPUs capabilities, you are also doubling the number, size and scope
>>> of problems you have to deal with.
>>
>> ???  My CPU design did not specify the data size, only the instruction
>> size.  I didn't have a problem adjusting the data size to suit my
>> application.
>
> I suppose you can parameterize the data size, and later change the
> definition of the parameter to suit.

Not just parameters, but the instruction format doesn't care.  Literals 
are built up in 7 bit chunks from an 8 bit instruction or 8 bit chunks 
with a 9 bit instruction since many FPGAs have memory and multipliers 9 
bit wide multiples.  The data path has no restrictions on width.


> The problem - for me - is the underlying result which still needs to fit
> in the real world. This may have something to do with the way I cram as
> much "stuff" into a chip as I can. It was only here that I learned you
> should consider your chip "full" when it start reaching 80% utilization.
> For me, over 95% is common.

I'm not sure how that related to CPU designs.  It has to be a very 
complex CPU to not fit in any but the very smallest FPGAs.  My CPU was 
about 600 LUTs which is not uncommon for MISC.


> Adding a single bit to a round number can throw the synthesis results way
> out of optimum. Adding one more can make the gate chain too long to fit
> into a clock cycle. Changing the clock period can be impossible because
> the design could have several other interlocking clocks. And on and on.

Now you are way outside the issues of CPU design.  Now you are in the 
design of your application.


> For example - I discovered that the synthesis tool I used (Lattices
> synthesizer) would produce a sub-optimal result if a unit - say a module
> - had even a single odd-sized register. Changing the register sizes to
> even numbers makes synthesis much better, even if it does throw away a
> bit.

What was suboptimal about a register?  What sort of unit?


>>>>> Does simulation count? :D
>>>>
>>>> Yes.  Also in emulation, as by a real FPGA product, but one which does
>>>> not plug into a socket, but is its own entire creation.  Here's an
>>>> Aleksander who created a 486 SX CPU (it has not integrated FPU):
>>>>
>>>>       https://github.com/alfikpl/ao486
>>>
>>> Verily, I shall review this. I'm starting to get the impression that
>>> all the stuff I'm making on my own has already been solved, but hasn't
>>> been advertised. I'm working on my dream computer, but these solved
>>> systems constantly keep popping up. Maybe all of it has already been
>>> solved?
>>
>> Exactly what is your dream computer?
>
> A device whose design can fit in my head, that is transparent and
> serviceable on all levels, free(-as-in-freedom), secure and usable for
> real-world tasks. I should probably put "usable" at the top of the
> list. :)
>
> Right now, that would mean a FPGA-implemented FOSH SoC that is self-
> contained. That means, which can regenerate the images and binaries of
> itself, by itself (so you don't need a second computer for that).

I thought there was already a CPU design like that.  RISC-V  Does that 
not fit your description?  Check out this page for ideas...

http://www.lowrisc.org/

-- 

Rick C

Article: 158841
Subject: Help finding Xilinx software for HW-130 programmer
From: Tim Regeant <TimRegeant@gmail.com>
Date: Tue, 3 May 2016 14:23:58 -0400
Links: << >>  << T >>  << A >>
I am searching for some Xilinx programmer software for the HW-130 unit 
from around 1996-2000.

Looking the the DOS version.  The filename was HW130.ZIP

Also looking for the 16-bit windows version HW130W.ZIP.

Thank you for any help you can offer!

Article: 158842
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: rickman <gnuarm@gmail.com>
Date: Tue, 3 May 2016 14:32:16 -0400
Links: << >>  << T >>  << A >>
On 5/3/2016 2:23 PM, Tim Regeant wrote:
> I am searching for some Xilinx programmer software for the HW-130 unit
> from around 1996-2000.
>
> Looking the the DOS version.  The filename was HW130.ZIP
>
> Also looking for the 16-bit windows version HW130W.ZIP.
>
> Thank you for any help you can offer!

I have software from that era along with a license key.  I could get it 
to you.

-- 

Rick C

Article: 158843
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: Tim Regeant <TimRegeant@gmail.com>
Date: Tue, 3 May 2016 14:50:22 -0400
Links: << >>  << T >>  << A >>
On 5/3/2016 2:32 PM, rickman wrote:
> On 5/3/2016 2:23 PM, Tim Regeant wrote:
>> I am searching for some Xilinx programmer software for the HW-130 unit
>> from around 1996-2000.
>>
>> Looking the the DOS version.  The filename was HW130.ZIP
>>
>> Also looking for the 16-bit windows version HW130W.ZIP.
>>
>> Thank you for any help you can offer!
>
> I have software from that era along with a license key.  I could get it
> to you.
>

Sure, shoot me an email.  Thanks.

Article: 158844
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 3 May 2016 11:57:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, May 3, 2016 at 2:50:26 PM UTC-4, Tim Regeant wrote:
> On 5/3/2016 2:32 PM, rickman wrote:
> > On 5/3/2016 2:23 PM, Tim Regeant wrote:
> >> I am searching for some Xilinx programmer software for the HW-130 unit
> >> from around 1996-2000.
> >>
> >> Looking the the DOS version.  The filename was HW130.ZIP
> >> Also looking for the 16-bit windows version HW130W.ZIP.
> >> Thank you for any help you can offer!
> >
> > I have software from that era along with a license key.  I could get it
> > to you.
> 
> Sure, shoot me an email.  Thanks.

Make sure it's legal.  Some companies maintain licensing restrictions
even on obsolete products.

Best regards,
Rick C. Hodgin

Article: 158845
Subject: Re: Source control and ip cores
From: wzab01@gmail.com
Date: Wed, 4 May 2016 09:55:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I have added support for "Block Design" components to my vextproj project.
There is also a simple demo added, running on the Z-Turn board (http://www.myirtech.com/list.asp?id=502). 
The demo compiles the bitstream from the project built using the EPRJ files.
Additionally the demo allows you to compile Linux with the appropriate device driver and test program, using the Buildroot environment.

With best regards,
Wojtek

Article: 158846
Subject: Re: Source control and ip cores
From: wzab01@gmail.com
Date: Wed, 4 May 2016 09:56:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu =C5=9Broda, 4 maja 2016 18:55:44 UTC+2 u=C5=BCytkownik wza...@gmail.=
com napisa=C5=82:
> Hi,
> I have added support for "Block Design" components to my vextproj project=
.
> There is also a simple demo added, running on the Z-Turn board (http://ww=
w.myirtech.com/list.asp?id=3D502).=20
> The demo compiles the bitstream from the project built using the EPRJ fil=
es.
> Additionally the demo allows you to compile Linux with the appropriate de=
vice driver and test program, using the Buildroot environment.
>=20
> With best regards,
> Wojtek

Of course the project is still at https://github.com/wzab/vextproj

Article: 158847
Subject: Matlab-to-Gates for Xilinx
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 5 May 2016 16:34:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does Xilinx still make a Matlab (not Simulink) -to-gates tool?  I don't thi=
nk so, but I was just wondering.  Not that I'm looking for one; I was just =
wondering.  In theory, it would be nice, since I model most things in Matla=
b before writing Verilog, but such tools usually aren't great at optimizing=
.

Article: 158848
Subject: Re: Matlab-to-Gates for Xilinx
From: wzab01@gmail.com
Date: Sat, 7 May 2016 05:40:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu pi=C4=85tek, 6 maja 2016 01:35:04 UTC+2 u=C5=BCytkownik Kevin Neilso=
n napisa=C5=82:
> Does Xilinx still make a Matlab (not Simulink) -to-gates tool?  I don't t=
hink so, but I was just wondering.  Not that I'm looking for one; I was jus=
t wondering.  In theory, it would be nice, since I model most things in Mat=
lab before writing Verilog, but such tools usually aren't great at optimizi=
ng.

Do you mean Xilinx System Generator?
I think, here you can find more info about its current state.

http://www.xilinx.com/products/design-tools/vivado/integration/sysgen.html

http://www.xilinx.com/support/documentation-navigation/design-hubs/dh0014-v=
ivado-system-generator-hub.html


With best regard,
Wojtek

Article: 158849
Subject: Re: Matlab-to-Gates for Xilinx
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Mon, 9 May 2016 10:31:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
I meant *code* conversion, not Simulink (schematic) conversion.



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
2019JanFebMar2019

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