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
2017JanFebMarApr2017

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 159175

Article: 159175
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Sun, 28 Aug 2016 11:20:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, August 27, 2016 at 11:09:26 PM UTC-7, rickman wrote:

> > I am thinking about getting a board with Xilinx FPGA, probably one of
> > the older Virtex ones. Found this on ebay:
> > http://www.ebay.com/itm/XILINX-VIRTEX-4-XC4VFX100-FPGA-kit-Development-=
board-XKF4/181791876772
> > , any comments?
>=20
> Why an older FPGA?  Is it price?
>=20
Yes. The newer Virtex boards cost a lot more (the ones using Virtex 6 or 7 =
run into thousands of dollars).
The only reason I am thinking of Xilinx is because it is probably the most =
used FPGA (along with maybe Altera), so I thought having it on my resume mi=
ght provide some advantage.

> I have *no* idea what that could be.  As I mentioned, my understanding=20
> is the TCP/IP protocol in particular is *very* complex and people don't=
=20
> want to implement their own software on a CPU, much less in hardware.=20
> I'm not sure what an "offload engine" would be other than a dedicated=20
> CPU, optimized for TCP/IP.  But if you have a CM4 in the device, why not=
=20
> use that?
>
Because the main purpose of this exercise is to design some network protoco=
l in real hardware (FPGA) so I can make myself marketable for jobs in that =
area. If the network protocol part is too complicated as a side project, th=
en I might just have to write some other (simpler) design and at least beco=
me familiar with the FPGA aspects of design.



Article: 159176
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Sun, 28 Aug 2016 11:26:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 28, 2016 at 12:11:47 AM UTC-7, Tom Gardner wrote:
> On 27/08/16 18:20, PM X wrote:
> > I meant some part of the TCP/IP stack implemented in actual hardware an=
d running in the FPGA. For example, a TCP Offload Engine, which implements =
the whole TCP/IP stack in hardware. Now, I understand that is something eno=
rmous and do not want to work on something that big for just a side/hobby p=
roject. But something in that area with less complexity is what I am lookin=
g for. I just don't have a good idea of what that could be, so having some =
clear definition will help.
>=20
> Protocol stack offload engines have two fundamental "issues".
>=20
> Firstly the time and latency required to get the packets
> to/from the main CPU. That significantly affects performance.
>=20
> Secondly the point that TCP is and end-to-end protocol
> and will correct protocol errors between or in the
> endpoints. An offload engine becomes the endpoint, so
> errors between the offload engine and the main CPU will
> not be corrected.
>=20
> The processing required to reliably transfer packets
> to/from the main CPU bears a lot of similarity to TCP!
>=20
> TCP in FPGA makes sense where
>   - the lowest latency is required, and
>   - where simplifying assumptions can be made, and
>   - where the end terminal logic is also done in the FPGA
> e.g. high frequency trading, where they put the business
> trading rules in hardware to minimise latency

As a matter of fact, I am doing this to prepare myself for interviews in FP=
GA design role in high frequency trading (in maybe 3-6 months time). Is the=
re any simpler project that you could suggest that would be in the general =
area of network protocols (maybe like a stripped down version) that could b=
e implemented in FPGA? Thanks!

Article: 159177
Subject: Re: Help me choose an FPGA to design network protocols
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 28 Aug 2016 20:23:28 +0100
Links: << >>  << T >>  << A >>
On 28/08/16 19:26, PM X wrote:
> On Sunday, August 28, 2016 at 12:11:47 AM UTC-7, Tom Gardner wrote:
>> On 27/08/16 18:20, PM X wrote:
>>> I meant some part of the TCP/IP stack implemented in actual hardware and running in the FPGA. For example, a TCP Offload Engine, which implements the whole TCP/IP stack in hardware. Now, I understand that is something enormous and do not want to work on something that big for just a side/hobby project. But something in that area with less complexity is what I am looking for. I just don't have a good idea of what that could be, so having some clear definition will help.
>>
>> Protocol stack offload engines have two fundamental "issues".
>>
>> Firstly the time and latency required to get the packets
>> to/from the main CPU. That significantly affects performance.
>>
>> Secondly the point that TCP is and end-to-end protocol
>> and will correct protocol errors between or in the
>> endpoints. An offload engine becomes the endpoint, so
>> errors between the offload engine and the main CPU will
>> not be corrected.
>>
>> The processing required to reliably transfer packets
>> to/from the main CPU bears a lot of similarity to TCP!
>>
>> TCP in FPGA makes sense where
>>    - the lowest latency is required, and
>>    - where simplifying assumptions can be made, and
>>    - where the end terminal logic is also done in the FPGA
>> e.g. high frequency trading, where they put the business
>> trading rules in hardware to minimise latency
>
> As a matter of fact, I am doing this to prepare myself for interviews in FPGA design role in high frequency trading (in maybe 3-6 months time). Is there any simpler project that you could suggest that would be in the general area of network protocols (maybe like a stripped down version) that could be implemented in FPGA? Thanks!

Based on precisely *zero* evidence and only 30s thought,
I would guess the networking stack is known technology,
whereas business/trading rules are newer.

ISTR seeing horrendously expensive boards (worth about
1ms of HFT!) with large numbers of big FPGAs and
networking. If that's correct then partitioning the
trading rules across FPGAs might be interesting. Or not.


Article: 159178
Subject: Re: Help me choose an FPGA to design network protocols
From: rickman <gnuarm@gmail.com>
Date: Sun, 28 Aug 2016 16:51:52 -0400
Links: << >>  << T >>  << A >>
On 8/28/2016 2:26 PM, PM X wrote:
> On Sunday, August 28, 2016 at 12:11:47 AM UTC-7, Tom Gardner wrote:
>> On 27/08/16 18:20, PM X wrote:
>>> I meant some part of the TCP/IP stack implemented in actual hardware and running in the FPGA. For example, a TCP Offload Engine, which implements the whole TCP/IP stack in hardware. Now, I understand that is something enormous and do not want to work on something that big for just a side/hobby project. But something in that area with less complexity is what I am looking for. I just don't have a good idea of what that could be, so having some clear definition will help.
>>
>> Protocol stack offload engines have two fundamental "issues".
>>
>> Firstly the time and latency required to get the packets
>> to/from the main CPU. That significantly affects performance.
>>
>> Secondly the point that TCP is and end-to-end protocol
>> and will correct protocol errors between or in the
>> endpoints. An offload engine becomes the endpoint, so
>> errors between the offload engine and the main CPU will
>> not be corrected.
>>
>> The processing required to reliably transfer packets
>> to/from the main CPU bears a lot of similarity to TCP!
>>
>> TCP in FPGA makes sense where
>>   - the lowest latency is required, and
>>   - where simplifying assumptions can be made, and
>>   - where the end terminal logic is also done in the FPGA
>> e.g. high frequency trading, where they put the business
>> trading rules in hardware to minimise latency
>
> As a matter of fact, I am doing this to prepare myself for interviews in FPGA design role in high frequency trading (in maybe 3-6 months time). Is there any simpler project that you could suggest that would be in the general area of network protocols (maybe like a stripped down version) that could be implemented in FPGA? Thanks!

Ok, that explains a lot.  I would suggest that you start with learning 
IP stack software.  Before you can implement it in the FPGA you have to 
understand it.  So first learn IP stack software.  Once you understand 
how that works you can decide how best to implement it in logic.

-- 

Rick C

Article: 159179
Subject: Re: Help me choose an FPGA to design network protocols
From: Rob Doyle <radioengr@gmail.com>
Date: Sun, 28 Aug 2016 23:33:34 -0700
Links: << >>  << T >>  << A >>
On 8/28/2016 1:51 PM, rickman wrote:
> On 8/28/2016 2:26 PM, PM X wrote:
>> On Sunday, August 28, 2016 at 12:11:47 AM UTC-7, Tom Gardner wrote:
>>> On 27/08/16 18:20, PM X wrote:
>>>> I meant some part of the TCP/IP stack implemented in actual hardware
>>>> and running in the FPGA. For example, a TCP Offload Engine, which
>>>> implements the whole TCP/IP stack in hardware. Now, I understand
>>>> that is something enormous and do not want to work on something that
>>>> big for just a side/hobby project. But something in that area with
>>>> less complexity is what I am looking for. I just don't have a good
>>>> idea of what that could be, so having some clear definition will help.
>>>
>>> Protocol stack offload engines have two fundamental "issues".
>>>
>>> Firstly the time and latency required to get the packets
>>> to/from the main CPU. That significantly affects performance.
>>>
>>> Secondly the point that TCP is and end-to-end protocol
>>> and will correct protocol errors between or in the
>>> endpoints. An offload engine becomes the endpoint, so
>>> errors between the offload engine and the main CPU will
>>> not be corrected.
>>>
>>> The processing required to reliably transfer packets
>>> to/from the main CPU bears a lot of similarity to TCP!
>>>
>>> TCP in FPGA makes sense where
>>>   - the lowest latency is required, and
>>>   - where simplifying assumptions can be made, and
>>>   - where the end terminal logic is also done in the FPGA
>>> e.g. high frequency trading, where they put the business
>>> trading rules in hardware to minimise latency
>>
>> As a matter of fact, I am doing this to prepare myself for interviews
>> in FPGA design role in high frequency trading (in maybe 3-6 months
>> time). Is there any simpler project that you could suggest that would
>> be in the general area of network protocols (maybe like a stripped
>> down version) that could be implemented in FPGA? Thanks!
>
> Ok, that explains a lot.  I would suggest that you start with learning
> IP stack software.  Before you can implement it in the FPGA you have to
> understand it.  So first learn IP stack software.  Once you understand
> how that works you can decide how best to implement it in logic.

UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.

For example:

http://www.fpga4fun.com/10BASE-T.html

OK. It is only 10Base-T. But it's not that different than the 10GbE that
we do.

You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00

http://store.digilentinc.com/pmodnic100-network-interface-controller/

It won't be low latency (the NIC has an SPI serial interface) but it 
will teach concepts.

Rob.


Article: 159180
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Mon, 29 Aug 2016 01:58:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 
> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
> 
> For example:
> 
> http://www.fpga4fun.com/10BASE-T.html
> 
> OK. It is only 10Base-T. But it's not that different than the 10GbE that
> we do.
> 
> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
> 
> http://store.digilentinc.com/pmodnic100-network-interface-controller/
> 
> It won't be low latency (the NIC has an SPI serial interface) but it 
> will teach concepts.
> 
> Rob.

Thanks. Is this the board you are referring to?
http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/

If so, this board doesn't seem to have SPI (at least no listed in the description). Also, do you think this board has enough capacity (in terms of logic elements, etc.) to support a fairly complicated design like UDP/IP?

Article: 159181
Subject: Re: Help me choose an FPGA to design network protocols
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 29 Aug 2016 10:17:43 +0100 (BST)
Links: << >>  << T >>  << A >>
PM X <pinaki2@gmail.com> wrote:
> As a matter of fact, I am doing this to prepare myself for interviews in
> FPGA design role in high frequency trading (in maybe 3-6 months time).  Is
> there any simpler project that you could suggest that would be in the
> general area of network protocols (maybe like a stripped down version)
> that could be implemented in FPGA?  Thanks!

I'd start bottom-up.

First, get the PHY working.  You probably want a single speed without
any rate switching (eg 1G, 10G), because anything else gets messy with
clock reconfiguration.  The choice will likely depend on your board.
(You can't really test it at this point).  Hopefully your board vendor has
example code for this.

Then drop in a vendor MAC component.  I've used the Altera ones and they're
not too bad: there are pipes on the side for streams in and out which are
easy to deal with.  There is a memory mapped interface for configuration -
you may need to implement that to configure it, or maybe the defaults are
OK.  (To configure, use a soft core - NIOS or Microblaze or whatever).

On the subject of board choice, I'd suggest avoiding anything with an
external MAC chip (external PHY is OK) because they expect to be driven from
a processor, while on FPGA it's all about packet pipes.  Likewise a MAC as
part of a CPU subsystem (eg a Zynq PS, Altera SoC-FPGA HPS) should be avoided
because they usually have the same problem, as well as being awkward
poorly-documented third-party IP where you essentially have to use the Linux
driver.

Once you have the MAC working, you have layer 2 packets in and out (you can
see MAC addresses etc).  Then you can start building up the layers (eg do IP
and ARP).  The MAC will probably give you some help for layer 2 (eg compute
checksums for you) but you're on your own after that.

Building up the layers is something you can simulate, while doing the
plumbing of the MAC you can only test in hardware.  I'd suggest writing a
testbench that simulates pushing layer 2 packets between two simulated
endpoints, and you can replace that by MAC+PHY on hardware when necessary.

If you want experience of networking on FPGA, you don't need to do a full
TCP stack to do that: much of the principles of pushing packets about and
dealing with vendor IP cores is the same irrespective of the packet format. 
If it makes you think about latency and meeting timing, that's a useful
thing.

If you want to learn about the vagaries of TCP, IPv6, etc I'd suggest
starting from software first.  Maybe find some NIC with a non-scary
interface and program it directly (with no OS support).  I'm thinking
something old like a PCI NE2000 (eg RTL8139) that isn't as complex as a
modern card - the Intel gigabit E1000(e) series (8254x, 8257x, I21x) are
well documented but a bit more complex.  While you can do this from FPGA,
it's much harder to debug.

Theo

Article: 159182
Subject: Re: Need help finding Synario Futurenet 6.10
From: Tim Regeant <TimRegeant@gmail.com>
Date: Mon, 29 Aug 2016 10:24:03 -0400
Links: << >>  << T >>  << A >>
On 8/28/2016 11:49 AM, Tim Regeant wrote:
> Anyone know where I can find this vintage software?
>
> I am looking for the verion 6.10 free with dongle not required.
>
> I think Synario was the one to release the free version.
>
> Used to be at the ftp site ftp://ftp.synario.com but can't reach it now.
>
> Thanks for any help you can offer.

Software has been found, thanks.

Article: 159183
Subject: Re: Help me choose an FPGA to design network protocols
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 29 Aug 2016 10:53:51 -0500
Links: << >>  << T >>  << A >>


On 8/26/2016 5:47 PM, PM X wrote:
> Hi all,
> I have over a decade of experience in hardware design, but almost all of it is in ASIC. I had done some FPGA projects in school, but nothing after that. So after all these years, I want to work on some personal FPGA projects (mainly to prepare myself for future job interviews). I have the following two questions.
>
> 1. What is an FPGA board that I can buy for this purpose? I am probably looking to do something not too basic (since I already have a lot of experience in design), at the same time I do not want to make it a super complicated full time project either. I prefer Xilinx (but I am open) and something less than $250 will be good. Note that question #2 might also affect the choice of board.
>
> 2. Once I have the FPGA board, I would like to implement some design involving network protocol (like TCP/IP, UDP, etc.). However, I have not worked on these network layers before and don't have an extensive knowledge on them either (other than what I had read in school long ago), so I do not have a very clear picture of what to do. Is there any open source design available on this? Or any projects with specific definitions that I can understand and then start implementing?
>
> Thanks!
>

Right off the bat  I'm not much of an expert so maybe some that are more 
experienced can comment. Have you looked at the Digilent Arty Artix 7 
FPGA board? It's inexpensive at $99, and has a built in Ethernet 
Physical, and it mentions that it comes with A MAC IP so you are off to 
a start.  It has  35K cells so I'm not familiar if that would be enough 
to implement the rest of the needed logic. It has both Arduino, and Pmod 
connectors so if desired you can add an external Ethernet module that 
are available in several chip versions.

< 
http://store.digilentinc.com/arty-board-artix-7-fpga-development-board-for-makers-and-hobbyists/ 
  >

Here is one external Ethernet adapter, there are many other available 
from other places.

<  http://store.digilentinc.com/pmodnic100-network-interface-controller/  >


-- 
Cecil - k5nwa

Article: 159184
Subject: Re: Help me choose an FPGA to design network protocols
From: rickman <gnuarm@gmail.com>
Date: Mon, 29 Aug 2016 14:32:19 -0400
Links: << >>  << T >>  << A >>
On 8/29/2016 4:58 AM, PM X wrote:
>>
>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
>>
>> For example:
>>
>> http://www.fpga4fun.com/10BASE-T.html
>>
>> OK. It is only 10Base-T. But it's not that different than the 10GbE that
>> we do.
>>
>> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
>>
>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
>>
>> It won't be low latency (the NIC has an SPI serial interface) but it
>> will teach concepts.
>>
>> Rob.
>
> Thanks. Is this the board you are referring to?
> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
>
> If so, this board doesn't seem to have SPI (at least no listed in the description). Also, do you think this board has enough capacity (in terms of logic elements, etc.) to support a fairly complicated design like UDP/IP?

What do you mean it doesn't have SPI?  SPI is a simple shift register 
interface which can *easily* be implemented in an FPGA (or MCU) using 
the GPIOs.

Do you mean ISP, in system programming?  If it doesn't have ISP how do 
you load your design?

-- 

Rick C

Article: 159185
Subject: Re: Help me choose an FPGA to design network protocols
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 29 Aug 2016 13:38:25 -0500
Links: << >>  << T >>  << A >>


On 8/29/2016 1:32 PM, rickman wrote:
> On 8/29/2016 4:58 AM, PM X wrote:
>>>
>>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
>>>
>>> For example:
>>>
>>> http://www.fpga4fun.com/10BASE-T.html
>>>
>>> OK. It is only 10Base-T. But it's not that different than the 10GbE that
>>> we do.
>>>
>>> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
>>>
>>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
>>>
>>> It won't be low latency (the NIC has an SPI serial interface) but it
>>> will teach concepts.
>>>
>>> Rob.
>>
>> Thanks. Is this the board you are referring to?
>> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
>>
>>
>> If so, this board doesn't seem to have SPI (at least no listed in the
>> description). Also, do you think this board has enough capacity (in
>> terms of logic elements, etc.) to support a fairly complicated design
>> like UDP/IP?
>
> What do you mean it doesn't have SPI?  SPI is a simple shift register
> interface which can *easily* be implemented in an FPGA (or MCU) using
> the GPIOs.
>
> Do you mean ISP, in system programming?  If it doesn't have ISP how do
> you load your design?
>

It's a FPGA, you can add SPI easily, there are IPs for free to allow 
that to happen.

In my post I was also going to mention the BASYS-3  board, I left it out 
because the Arty Board has a ton of memory available that this one 
doesn't but this on has a lot of switches and LED which can be handy.
-- 
Cecil - k5nwa

Article: 159186
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Mon, 29 Aug 2016 12:36:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, August 29, 2016 at 11:32:23 AM UTC-7, rickman wrote:
> On 8/29/2016 4:58 AM, PM X wrote:
> >>
> >> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
> >>
> >> For example:
> >>
> >> http://www.fpga4fun.com/10BASE-T.html
> >>
> >> OK. It is only 10Base-T. But it's not that different than the 10GbE that
> >> we do.
> >>
> >> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
> >>
> >> http://store.digilentinc.com/pmodnic100-network-interface-controller/
> >>
> >> It won't be low latency (the NIC has an SPI serial interface) but it
> >> will teach concepts.
> >>
> >> Rob.
> >
> > Thanks. Is this the board you are referring to?
> > http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
> >
> > If so, this board doesn't seem to have SPI (at least no listed in the description). Also, do you think this board has enough capacity (in terms of logic elements, etc.) to support a fairly complicated design like UDP/IP?
> 
> What do you mean it doesn't have SPI?  SPI is a simple shift register 
> interface which can *easily* be implemented in an FPGA (or MCU) using 
> the GPIOs.
> 
> Do you mean ISP, in system programming?  If it doesn't have ISP how do 
> you load your design?
> 
> -- 
> 
> Rick C

I meant I didn't see a (dedicated) SPI interface. But you're right. SPI protocol just needs 4 general purpose pins, so using GPIOs should do it.

Article: 159187
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Mon, 29 Aug 2016 12:40:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, August 29, 2016 at 11:38:27 AM UTC-7, Cecil Bayona wrote:
> On 8/29/2016 1:32 PM, rickman wrote:
> > On 8/29/2016 4:58 AM, PM X wrote:
> >>>
> >>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
> >>>
> >>> For example:
> >>>
> >>> http://www.fpga4fun.com/10BASE-T.html
> >>>
> >>> OK. It is only 10Base-T. But it's not that different than the 10GbE t=
hat
> >>> we do.
> >>>
> >>> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200=
.00
> >>>
> >>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
> >>>
> >>> It won't be low latency (the NIC has an SPI serial interface) but it
> >>> will teach concepts.
> >>>
> >>> Rob.
> >>
> >> Thanks. Is this the board you are referring to?
> >> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recomm=
ended-for-introductory-users/
> >>
> >>
> >> If so, this board doesn't seem to have SPI (at least no listed in the
> >> description). Also, do you think this board has enough capacity (in
> >> terms of logic elements, etc.) to support a fairly complicated design
> >> like UDP/IP?
> >
> > What do you mean it doesn't have SPI?  SPI is a simple shift register
> > interface which can *easily* be implemented in an FPGA (or MCU) using
> > the GPIOs.
> >
> > Do you mean ISP, in system programming?  If it doesn't have ISP how do
> > you load your design?
> >
>=20
> It's a FPGA, you can add SPI easily, there are IPs for free to allow=20
> that to happen.
>=20
> In my post I was also going to mention the BASYS-3  board, I left it out=
=20
> because the Arty Board has a ton of memory available that this one=20
> doesn't but this on has a lot of switches and LED which can be handy.
> --=20
> Cecil - k5nwa

OK, thanks. I will check out both of them. What is the largest design you (=
or someone you know) have implemented on these boards? The Artix line seems=
 to be lower end than Virtex line, so trying to get an idea if they can sup=
port somewhat complicated designs.

Article: 159188
Subject: Re: Help me choose an FPGA to design network protocols
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 29 Aug 2016 15:30:26 -0500
Links: << >>  << T >>  << A >>


On 8/29/2016 2:40 PM, PM X wrote:
> On Monday, August 29, 2016 at 11:38:27 AM UTC-7, Cecil Bayona wrote:
>> On 8/29/2016 1:32 PM, rickman wrote:
>>> On 8/29/2016 4:58 AM, PM X wrote:
>>>>>
>>>>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
>>>>>
>>>>> For example:
>>>>>
>>>>> http://www.fpga4fun.com/10BASE-T.html
>>>>>
>>>>> OK. It is only 10Base-T. But it's not that different than the 10GbE that
>>>>> we do.
>>>>>
>>>>> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
>>>>>
>>>>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
>>>>>
>>>>> It won't be low latency (the NIC has an SPI serial interface) but it
>>>>> will teach concepts.
>>>>>
>>>>> Rob.
>>>>
>>>> Thanks. Is this the board you are referring to?
>>>> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
>>>>
>>>>
>>>> If so, this board doesn't seem to have SPI (at least no listed in the
>>>> description). Also, do you think this board has enough capacity (in
>>>> terms of logic elements, etc.) to support a fairly complicated design
>>>> like UDP/IP?
>>>
>>> What do you mean it doesn't have SPI?  SPI is a simple shift register
>>> interface which can *easily* be implemented in an FPGA (or MCU) using
>>> the GPIOs.
>>>
>>> Do you mean ISP, in system programming?  If it doesn't have ISP how do
>>> you load your design?
>>>
>>
>> It's a FPGA, you can add SPI easily, there are IPs for free to allow
>> that to happen.
>>
>> In my post I was also going to mention the BASYS-3  board, I left it out
>> because the Arty Board has a ton of memory available that this one
>> doesn't but this on has a lot of switches and LED which can be handy.
>> --
>> Cecil - k5nwa
>
> OK, thanks. I will check out both of them. What is the largest design you (or someone you know) have implemented on these boards? The Artix line seems to be lower end than Virtex line, so trying to get an idea if they can support somewhat complicated designs.
>
Nothing Fancy, that is why in my earlier post I mentioned that I don't 
have a lot of experience. I been working  a 32 bit stack based CPU, but 
it's a work in progress, I'm still sorting it out, it taken less than 
20% of the chip, but a stack CPU are rather simple compared to other 
CPU's, when finished it should be pretty nice, most instructions take 
one clock to execute, and it used packed instructions, 5 instructions to 
a word fetch. Originally it was on a Lattice Brevia2, I am now 
converting it to a Artix-7 board, but there is software involved too so 
it's going slow and I'm learning as I go.
-- 
Cecil - k5nwa

Article: 159189
Subject: Re: Help me choose an FPGA to design network protocols
From: rickman <gnuarm@gmail.com>
Date: Mon, 29 Aug 2016 20:53:30 -0400
Links: << >>  << T >>  << A >>
On 8/29/2016 3:40 PM, PM X wrote:
> On Monday, August 29, 2016 at 11:38:27 AM UTC-7, Cecil Bayona wrote:
>> On 8/29/2016 1:32 PM, rickman wrote:
>>> On 8/29/2016 4:58 AM, PM X wrote:
>>>>>
>>>>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
>>>>>
>>>>> For example:
>>>>>
>>>>> http://www.fpga4fun.com/10BASE-T.html
>>>>>
>>>>> OK. It is only 10Base-T. But it's not that different than the 10GbE that
>>>>> we do.
>>>>>
>>>>> You can get a crappy NIC and Basys 3 Artix 7 board for less than $200.00
>>>>>
>>>>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
>>>>>
>>>>> It won't be low latency (the NIC has an SPI serial interface) but it
>>>>> will teach concepts.
>>>>>
>>>>> Rob.
>>>>
>>>> Thanks. Is this the board you are referring to?
>>>> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
>>>>
>>>>
>>>> If so, this board doesn't seem to have SPI (at least no listed in the
>>>> description). Also, do you think this board has enough capacity (in
>>>> terms of logic elements, etc.) to support a fairly complicated design
>>>> like UDP/IP?
>>>
>>> What do you mean it doesn't have SPI?  SPI is a simple shift register
>>> interface which can *easily* be implemented in an FPGA (or MCU) using
>>> the GPIOs.
>>>
>>> Do you mean ISP, in system programming?  If it doesn't have ISP how do
>>> you load your design?
>>>
>>
>> It's a FPGA, you can add SPI easily, there are IPs for free to allow
>> that to happen.
>>
>> In my post I was also going to mention the BASYS-3  board, I left it out
>> because the Arty Board has a ton of memory available that this one
>> doesn't but this on has a lot of switches and LED which can be handy.
>> --
>> Cecil - k5nwa
>
> OK, thanks. I will check out both of them. What is the largest design you (or someone you know) have implemented on these boards? The Artix line seems to be lower end than Virtex line, so trying to get an idea if they can support somewhat complicated designs.

No sure what "lower end" means in technical terms.  I expect the Artix 
line of FPGAs will easily support somewhat complicated designs for 
reasonable values of "somewhat complicated".

I suggest you not give much credence to marketing information and 
consider the chip specifications.  For the most part the important issue 
is the LUT count.  Otherwise the extra features are only useful if you 
need them.

-- 

Rick C

Article: 159190
Subject: Re: Help me choose an FPGA to design network protocols
From: rickman <gnuarm@gmail.com>
Date: Mon, 29 Aug 2016 20:55:47 -0400
Links: << >>  << T >>  << A >>
On 8/29/2016 4:30 PM, Cecil Bayona wrote:
>
>
> On 8/29/2016 2:40 PM, PM X wrote:
>> On Monday, August 29, 2016 at 11:38:27 AM UTC-7, Cecil Bayona wrote:
>>> On 8/29/2016 1:32 PM, rickman wrote:
>>>> On 8/29/2016 4:58 AM, PM X wrote:
>>>>>>
>>>>>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> http://www.fpga4fun.com/10BASE-T.html
>>>>>>
>>>>>> OK. It is only 10Base-T. But it's not that different than the
>>>>>> 10GbE that
>>>>>> we do.
>>>>>>
>>>>>> You can get a crappy NIC and Basys 3 Artix 7 board for less than
>>>>>> $200.00
>>>>>>
>>>>>> http://store.digilentinc.com/pmodnic100-network-interface-controller/
>>>>>>
>>>>>> It won't be low latency (the NIC has an SPI serial interface) but it
>>>>>> will teach concepts.
>>>>>>
>>>>>> Rob.
>>>>>
>>>>> Thanks. Is this the board you are referring to?
>>>>> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/
>>>>>
>>>>>
>>>>>
>>>>> If so, this board doesn't seem to have SPI (at least no listed in the
>>>>> description). Also, do you think this board has enough capacity (in
>>>>> terms of logic elements, etc.) to support a fairly complicated design
>>>>> like UDP/IP?
>>>>
>>>> What do you mean it doesn't have SPI?  SPI is a simple shift register
>>>> interface which can *easily* be implemented in an FPGA (or MCU) using
>>>> the GPIOs.
>>>>
>>>> Do you mean ISP, in system programming?  If it doesn't have ISP how do
>>>> you load your design?
>>>>
>>>
>>> It's a FPGA, you can add SPI easily, there are IPs for free to allow
>>> that to happen.
>>>
>>> In my post I was also going to mention the BASYS-3  board, I left it out
>>> because the Arty Board has a ton of memory available that this one
>>> doesn't but this on has a lot of switches and LED which can be handy.
>>> --
>>> Cecil - k5nwa
>>
>> OK, thanks. I will check out both of them. What is the largest design
>> you (or someone you know) have implemented on these boards? The Artix
>> line seems to be lower end than Virtex line, so trying to get an idea
>> if they can support somewhat complicated designs.
>>
> Nothing Fancy, that is why in my earlier post I mentioned that I don't
> have a lot of experience. I been working  a 32 bit stack based CPU, but
> it's a work in progress, I'm still sorting it out, it taken less than
> 20% of the chip, but a stack CPU are rather simple compared to other
> CPU's, when finished it should be pretty nice, most instructions take
> one clock to execute, and it used packed instructions, 5 instructions to
> a word fetch. Originally it was on a Lattice Brevia2, I am now
> converting it to a Artix-7 board, but there is software involved too so
> it's going slow and I'm learning as I go.

Just a comment on your stack processor.  I've done some design work with 
stack processors and read about a lot of designs.  In my humble opinion, 
if you have multiple cycle instructions, you are doing it wrong.  I 
don't want to steal the thread.  If you care to discuss this we can 
start another thread.

-- 

Rick C

Article: 159191
Subject: Zero Address CPU logic
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 29 Aug 2016 23:03:17 -0500
Links: << >>  << T >>  << A >>
On 8/29/2016 7:55 PM, rickman wrote:
 > On 8/29/2016 4:30 PM, Cecil Bayona wrote:
 >> Nothing Fancy, that is why in my earlier post I mentioned that I don't
 >> have a lot of experience. I been working  a 32 bit stack based CPU, but
 >> it's a work in progress, I'm still sorting it out, it taken less than
 >> 20% of the chip, but a stack CPU are rather simple compared to other
 >> CPU's, when finished it should be pretty nice, most instructions take
 >> one clock to execute, and it used packed instructions, 5 instructions to
 >> a word fetch. Originally it was on a Lattice Brevia2, I am now
 >> converting it to a Artix-7 board, but there is software involved too so
 >> it's going slow and I'm learning as I go.
 >
 > Just a comment on your stack processor.  I've done some design work with
 > stack processors and read about a lot of designs.  In my humble opinion,
 > if you have multiple cycle instructions, you are doing it wrong.  I
 > don't want to steal the thread.  If you care to discuss this we can
 > start another thread.
 >
I'm not sure why you think that it uses  multiple cock instruction, I 
mentioned that most occur in one clock, the exception is load immediate 
it takes the instruction fetch, then a second fetch for the 32 bit value 
to push on the stack, all others take one clock. Even that one can take 
place in one clock with extra hardware to fetch RAM with a buffer to 
hold two 32 bit words, an alternative is to use two clocks one to 
execute the other to fetch program instructions.

What is does have is multiple instructions on one program word, it's 
five instructions or one depending on what it is, jump, and call take 
the whole 32 bit word and is not packed, everything else is 5 
instructions to a 32 bit program word so you have fewer memory fetches.

-- 
Cecil - k5nwa

Article: 159192
Subject: Re: Zero Address CPU logic
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Aug 2016 02:11:21 -0400
Links: << >>  << T >>  << A >>
On 8/30/2016 12:03 AM, Cecil Bayona wrote:
> On 8/29/2016 7:55 PM, rickman wrote:
>> On 8/29/2016 4:30 PM, Cecil Bayona wrote:
>>> Nothing Fancy, that is why in my earlier post I mentioned that I don't
>>> have a lot of experience. I been working  a 32 bit stack based CPU, but
>>> it's a work in progress, I'm still sorting it out, it taken less than
>>> 20% of the chip, but a stack CPU are rather simple compared to other
>>> CPU's, when finished it should be pretty nice, most instructions take
>>> one clock to execute, and it used packed instructions, 5 instructions to
>>> a word fetch. Originally it was on a Lattice Brevia2, I am now
>>> converting it to a Artix-7 board, but there is software involved too so
>>> it's going slow and I'm learning as I go.
>>
>> Just a comment on your stack processor.  I've done some design work with
>> stack processors and read about a lot of designs.  In my humble opinion,
>> if you have multiple cycle instructions, you are doing it wrong.  I
>> don't want to steal the thread.  If you care to discuss this we can
>> start another thread.
>>
> I'm not sure why you think that it uses  multiple cock instruction, I
> mentioned that most occur in one clock, the exception is load immediate
> it takes the instruction fetch, then a second fetch for the 32 bit value
> to push on the stack, all others take one clock. Even that one can take
> place in one clock with extra hardware to fetch RAM with a buffer to
> hold two 32 bit words, an alternative is to use two clocks one to
> execute the other to fetch program instructions.
>
> What is does have is multiple instructions on one program word, it's
> five instructions or one depending on what it is, jump, and call take
> the whole 32 bit word and is not packed, everything else is 5
> instructions to a 32 bit program word so you have fewer memory fetches.

Are you using external memory?  The CPUs I've designed were 100% 
internal to the FPGA so there was no advantage to fetching multiple 
instructions.  In fact, the multiplexer needed was just more delay.

I thought you design was not one clock per instruction because of what 
you said.  Your design is using a single memory interface.  It is common 
for stack machines to separate data and instruction space.  But if you 
are working out of external memory that is not so easy.

I assume you have read the various similar work that has been done?  The 
J1 is very interesting in that it was so durn simple.  A true MISC 
design and effective.  If you meander over to comp.lang.forth there are 
folks there who have designed some MISC CPUs which have proven their 
worth.  Bernd Paysan designed the B16 which seems like an effective 
design.  I've never tried to work with it, but it sounds similar to 
yours in they way it combines multiple instructions into a single 
instruction word.

-- 

Rick C

Article: 159193
Subject: Re: Zero Address CPU logic
From: Cecil Bayona <cbayona@cbayona.com>
Date: Tue, 30 Aug 2016 03:49:37 -0500
Links: << >>  << T >>  << A >>


On 8/30/2016 1:11 AM, rickman wrote:
> On 8/30/2016 12:03 AM, Cecil Bayona wrote:
>> On 8/29/2016 7:55 PM, rickman wrote:
>>> On 8/29/2016 4:30 PM, Cecil Bayona wrote:
>>>> Nothing Fancy, that is why in my earlier post I mentioned that I don't
>>>> have a lot of experience. I been working  a 32 bit stack based CPU, but
>>>> it's a work in progress, I'm still sorting it out, it taken less than
>>>> 20% of the chip, but a stack CPU are rather simple compared to other
>>>> CPU's, when finished it should be pretty nice, most instructions take
>>>> one clock to execute, and it used packed instructions, 5
>>>> instructions to
>>>> a word fetch. Originally it was on a Lattice Brevia2, I am now
>>>> converting it to a Artix-7 board, but there is software involved too so
>>>> it's going slow and I'm learning as I go.
>>>
>>> Just a comment on your stack processor.  I've done some design work with
>>> stack processors and read about a lot of designs.  In my humble opinion,
>>> if you have multiple cycle instructions, you are doing it wrong.  I
>>> don't want to steal the thread.  If you care to discuss this we can
>>> start another thread.
>>>
>> I'm not sure why you think that it uses  multiple cock instruction, I
>> mentioned that most occur in one clock, the exception is load immediate
>> it takes the instruction fetch, then a second fetch for the 32 bit value
>> to push on the stack, all others take one clock. Even that one can take
>> place in one clock with extra hardware to fetch RAM with a buffer to
>> hold two 32 bit words, an alternative is to use two clocks one to
>> execute the other to fetch program instructions.
>>
>> What is does have is multiple instructions on one program word, it's
>> five instructions or one depending on what it is, jump, and call take
>> the whole 32 bit word and is not packed, everything else is 5
>> instructions to a 32 bit program word so you have fewer memory fetches.
>
> Are you using external memory?  The CPUs I've designed were 100%
> internal to the FPGA so there was no advantage to fetching multiple
> instructions.  In fact, the multiplexer needed was just more delay.
>
> I thought you design was not one clock per instruction because of what
> you said.  Your design is using a single memory interface.  It is common
> for stack machines to separate data and instruction space.  But if you
> are working out of external memory that is not so easy.
>
> I assume you have read the various similar work that has been done?  The
> J1 is very interesting in that it was so durn simple.  A true MISC
> design and effective.  If you meander over to comp.lang.forth there are
> folks there who have designed some MISC CPUs which have proven their
> worth.  Bernd Paysan designed the B16 which seems like an effective
> design.  I've never tried to work with it, but it sounds similar to
> yours in they way it combines multiple instructions into a single
> instruction word.
>
I think the multiple instructions is to save on program space, 32 bits 
to an instruction will eat up the memory space ways too quickly. It is a 
Von Newman machine with a single address space, code and data is all in 
the same space.

It uses three kinds of instruction formats, short and long, and double word.

A short instruction is 6 bits so you can cram 5 instruction to a memory 
word, so there are 64 possible instructions but the bare machine uses 27 
opcodes so there is room for additional instructions. The are things 
that require no addresses such as dup, swap, return, add, etc.

Long instructions take 30 bits, they are things like jump, call, 
including conditional versions, they include a 24 bit address as part of 
the instruction which can address 16MB of program space, the upper two 
bits are unused at present

There is a single two word instruction, which pushes the second 32 bit 
word into the stack, it itself is a 6 bit instruction and there can be 
more that one "LIT" instruction, each one has an additional word to use 
as a literal. Each 32 bit program word could have 6 LIT instructions 
with each one having an additional 32 bit word following the program 
code word so if you have six literal words packed into single 32 bit 
program word, it is followed by six 32 words containing the literal 
values, the program continues 7 words after the current 6 instruction 
word, of course one can have fewer literals.

The whole thing is like a packed instruction pipeline it minimizes the 
number of fetches but any control flow instruction cancels and dumps the 
current instruction queue and does a fetch at a different place since 
the IP has changed.

The job of packing the instructions into one word is handled by the 
Forth Compiler so the user does not see it, it just makes the program 
code smaller automatically. I did some test and 5 is too long a queue, 
when doing a 16 bit version it packs 3 instructions to a word and that 
version ends up with a shorter program area so it's more efficient, in 
part because Forth changes the Program Counter often so having a longer 
instruction queue waste instruction slots. on a 16 bit version adding 
some extra instructions would be nice so you end up with add with carry, 
subtract with borrow etc so it can handle 32 operations efficiently.

Overall its an efficient design but it could be improved as anything 
else could. One could add combined instructions where a return is 
combined with some regular instructions so it execute both in one clock.

Eventually I want to work with the J1, its a simpler 16 bit machine but 
since the instruction word contains multiple fields it can have 
instructions that do multiple operations at the same time naturally, 
with a more complex compiler packing multiple instructions it might save 
on program space. It does have very limited addressing space due to it's 
instructions limited to 16 bits.
-- 
Cecil - k5nwa

Article: 159194
Subject: Re: Zero Address CPU logic
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Aug 2016 05:35:06 -0400
Links: << >>  << T >>  << A >>
On 8/30/2016 4:49 AM, Cecil Bayona wrote:
>
>
> On 8/30/2016 1:11 AM, rickman wrote:
>> On 8/30/2016 12:03 AM, Cecil Bayona wrote:
>>> On 8/29/2016 7:55 PM, rickman wrote:
>>>> On 8/29/2016 4:30 PM, Cecil Bayona wrote:
>>>>> Nothing Fancy, that is why in my earlier post I mentioned that I don't
>>>>> have a lot of experience. I been working  a 32 bit stack based CPU,
>>>>> but
>>>>> it's a work in progress, I'm still sorting it out, it taken less than
>>>>> 20% of the chip, but a stack CPU are rather simple compared to other
>>>>> CPU's, when finished it should be pretty nice, most instructions take
>>>>> one clock to execute, and it used packed instructions, 5
>>>>> instructions to
>>>>> a word fetch. Originally it was on a Lattice Brevia2, I am now
>>>>> converting it to a Artix-7 board, but there is software involved
>>>>> too so
>>>>> it's going slow and I'm learning as I go.
>>>>
>>>> Just a comment on your stack processor.  I've done some design work
>>>> with
>>>> stack processors and read about a lot of designs.  In my humble
>>>> opinion,
>>>> if you have multiple cycle instructions, you are doing it wrong.  I
>>>> don't want to steal the thread.  If you care to discuss this we can
>>>> start another thread.
>>>>
>>> I'm not sure why you think that it uses  multiple cock instruction, I
>>> mentioned that most occur in one clock, the exception is load immediate
>>> it takes the instruction fetch, then a second fetch for the 32 bit value
>>> to push on the stack, all others take one clock. Even that one can take
>>> place in one clock with extra hardware to fetch RAM with a buffer to
>>> hold two 32 bit words, an alternative is to use two clocks one to
>>> execute the other to fetch program instructions.
>>>
>>> What is does have is multiple instructions on one program word, it's
>>> five instructions or one depending on what it is, jump, and call take
>>> the whole 32 bit word and is not packed, everything else is 5
>>> instructions to a 32 bit program word so you have fewer memory fetches.
>>
>> Are you using external memory?  The CPUs I've designed were 100%
>> internal to the FPGA so there was no advantage to fetching multiple
>> instructions.  In fact, the multiplexer needed was just more delay.
>>
>> I thought you design was not one clock per instruction because of what
>> you said.  Your design is using a single memory interface.  It is common
>> for stack machines to separate data and instruction space.  But if you
>> are working out of external memory that is not so easy.
>>
>> I assume you have read the various similar work that has been done?  The
>> J1 is very interesting in that it was so durn simple.  A true MISC
>> design and effective.  If you meander over to comp.lang.forth there are
>> folks there who have designed some MISC CPUs which have proven their
>> worth.  Bernd Paysan designed the B16 which seems like an effective
>> design.  I've never tried to work with it, but it sounds similar to
>> yours in they way it combines multiple instructions into a single
>> instruction word.
>>
> I think the multiple instructions is to save on program space, 32 bits
> to an instruction will eat up the memory space ways too quickly. It is a
> Von Newman machine with a single address space, code and data is all in
> the same space.

Again, that is a reflection of having a common address space for 
instructions and data.  My CPUs use 8 or 9 bits for instructions while 
being data size independent.  The instruction format does not imply any 
particular data bus size.


> It uses three kinds of instruction formats, short and long, and double
> word.
>
> A short instruction is 6 bits so you can cram 5 instruction to a memory
> word, so there are 64 possible instructions but the bare machine uses 27
> opcodes so there is room for additional instructions. The are things
> that require no addresses such as dup, swap, return, add, etc.
>
> Long instructions take 30 bits, they are things like jump, call,
> including conditional versions, they include a 24 bit address as part of
> the instruction which can address 16MB of program space, the upper two
> bits are unused at present
>
> There is a single two word instruction, which pushes the second 32 bit
> word into the stack, it itself is a 6 bit instruction and there can be
> more that one "LIT" instruction, each one has an additional word to use
> as a literal. Each 32 bit program word could have 6 LIT instructions
> with each one having an additional 32 bit word following the program
> code word so if you have six literal words packed into single 32 bit
> program word, it is followed by six 32 words containing the literal
> values, the program continues 7 words after the current 6 instruction
> word, of course one can have fewer literals.

I've shied away from multicycle instructions because it means more bits 
(1 bit in this case) to indicate the cycle count which is more input(s) 
to the decoder.  I wanted to try to keep the decoder as simple as possible.


> The whole thing is like a packed instruction pipeline it minimizes the
> number of fetches but any control flow instruction cancels and dumps the
> current instruction queue and does a fetch at a different place since
> the IP has changed.

The F18A does that.  Learning how to pack instructions into the word is 
a bit tricky.  Even harder is learning how to time execution, but that's 
because it is async and does not use a fixed frequency clock.


> The job of packing the instructions into one word is handled by the
> Forth Compiler so the user does not see it, it just makes the program
> code smaller automatically. I did some test and 5 is too long a queue,
> when doing a 16 bit version it packs 3 instructions to a word and that
> version ends up with a shorter program area so it's more efficient, in
> part because Forth changes the Program Counter often so having a longer
> instruction queue waste instruction slots. on a 16 bit version adding
> some extra instructions would be nice so you end up with add with carry,
> subtract with borrow etc so it can handle 32 operations efficiently.
>
> Overall its an efficient design but it could be improved as anything
> else could. One could add combined instructions where a return is
> combined with some regular instructions so it execute both in one clock.

One of the things I have looked at briefly is breaking out the three 
"engines" so each one is separately controlled by fields in the 
instruction.  This will require a larger instruction, but 16 bits should 
be enough.  Then many types of instructions could be combined.  I didn't 
pursue it because I didn't want to work on the assembler that would 
handle it.


> Eventually I want to work with the J1, its a simpler 16 bit machine but
> since the instruction word contains multiple fields it can have
> instructions that do multiple operations at the same time naturally,
> with a more complex compiler packing multiple instructions it might save
> on program space. It does have very limited addressing space due to it's
> instructions limited to 16 bits.

I seem to recall discussing this with someone else not too long ago.  I 
don't think there actually is much parallelism possible with the J1 
design.  You can combine a return instruction with arithmetic 
instructions, and there are fields to adjust the stack independently. 
So you might be able to combine say, 2DUP + in one instruction by using 
+ with a DSTACK +1 instead of a -1.  But the useful combos will be 
limited.  The utility is also limited by the instruction frequency. 
Only 35% of the instructions in the app the J1 was designed for are ALU 
instructions which are the only ones that can be paralleled.

In my CPU design I had separate "engines" for the data stack (ALU), the 
return stack (destination for literals, addresses for all operations and 
looping control) and the instruction fetch.  If each of these had 
separate fields in the instruction word there might be more opportunity 
for parallelism.  But as I said, I didn't pursue this because the 
software support would be messy.  I'd like to get back to that, but it 
won't happen any time soon.

-- 

Rick C

Article: 159195
Subject: Altera USB Blaster clone driver for STM32F1xx
From: Jim Horn <jamesludwighorn@gmail.com>
Date: Tue, 30 Aug 2016 11:01:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does anyone have the drivers for Windows 10 64 bit use of the STM32F1xx bas=
ed USB Blaster clones? They are readily available, inexpensive and the STM3=
2 Cortex CPU should have plenty of performance for these to work well. Howe=
ver, the firmware isn't fully Altera compatible so when connected via USB t=
hey crash the machine with a blue screen reboot.

I just received mine and for the price, ordering a different one would be w=
orth while but I would like to get this one working instead of waiting 1 to=
 2 weeks for another. And most vendors don't show which CPU theirs uses so =
I could end up with another that I can't use.

Any and all pointers will be most appreciated!

For reference, I'm running Quartus 16.0.2 in Windows 10 Enterprise, 64 bit.=
 The clone's PC board has a row of 11 vias for a header which I suspect is =
used for programming it, if anyone has ideas about that as well.

Best to you all -

Article: 159196
Subject: Re: Altera USB Blaster clone driver for STM32F1xx
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Tue, 30 Aug 2016 14:50:39 -0500
Links: << >>  << T >>  << A >>
On Tue, 30 Aug 2016 11:01:44 -0700, Jim Horn wrote:

> Does anyone have the drivers for Windows 10 64 bit use of the STM32F1xx
> based USB Blaster clones? They are readily available, inexpensive and
> the STM32 Cortex CPU should have plenty of performance for these to work
> well. However, the firmware isn't fully Altera compatible so when
> connected via USB they crash the machine with a blue screen reboot.
> 
> I just received mine and for the price, ordering a different one would
> be worth while but I would like to get this one working instead of
> waiting 1 to 2 weeks for another. And most vendors don't show which CPU
> theirs uses so I could end up with another that I can't use.
> 
> Any and all pointers will be most appreciated!
> 
> For reference, I'm running Quartus 16.0.2 in Windows 10 Enterprise, 64
> bit. The clone's PC board has a row of 11 vias for a header which I
> suspect is used for programming it, if anyone has ideas about that as
> well.
> 
> Best to you all -

Not what you want to hear, but you could maybe get things working with a 
virtual machine (i.e. VirtualBox) running a 32-bit Windows version.  
You'll be able to do everything from the existing machine, just more 
clunkily.

-- 

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

I'm looking for work -- see my website!

Article: 159197
Subject: Re: PALCE22v10 / GAL22v10 programming algorithms needed
From: lolinka04@gmail.com
Date: Thu, 1 Sep 2016 09:51:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
I wonder if they ever gave it to him ?
Would they do it now that these chips are no longer produced?



Article: 159198
Subject: Re: PALCE22v10 / GAL22v10 programming algorithms needed
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 01 Sep 2016 14:09:08 -0400
Links: << >>  << T >>  << A >>
lolinka04@gmail.com wrote:
> I wonder if they ever gave it to him ?
> Would they do it now that these chips are no longer produced?
> 
> 

If you're going to reply to an 18-year-old post, it would
be nice to quote the thread for those who don't keep that
many headers downloaded.

In any case, AMD is long out of the SPLD business, but the
22V10 still lives on.  Atmel is making them as the
ATF22V10:

http://www.atmel.com/Images/doc0735.pdf

The data sheet mentions "flash" technology, so I assume the
programming algorithm has changed since the EEPROM versions
made by Lattice, TI, and AMD.

Are you planning to build your own programmer?

-- 
Gabor

Article: 159199
Subject: Re: PALCE22v10 / GAL22v10 programming algorithms needed
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Thu, 1 Sep 2016 20:07:09 +0100
Links: << >>  << T >>  << A >>
On Thu, 1 Sep 2016 09:51:36 -0700 (PDT)
lolinka04@gmail.com wrote:

> I wonder if they ever gave it to him ?
> Would they do it now that these chips are no longer produced?

I did a project to program early Flash logic parts.  This
included a PC plugin board, borrowed equation compiler, and
configuration stream generator. 

Why might this ancient history be of interest?

Jan Coombs




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
2017JanFebMarApr2017

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