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 158800

Article: 158800
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 10 Apr 2016 19:26:36 +0100 (BST)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> I expect trying to get anything remotely like a critical mass is 
> virtually impossible.  There is an open source chip similar in size and 
> capability to the ARM processors called RISC-V that is getting wide 
> attention and will produce a chip soon.

RISC-V is an architecture, and various chips have been produced.  It's also
getting embedded in other products (eg as a tiny part of some other SoC).

My colleagues at LowRISC:
http://www.lowrisc.org/

are working on a fully open-source SoC based on the RISC-V architecture - ie
open source at the Verilog design level, including peripheral IP.  They
still face many challenges, including the need to use proprietary
ASIC tools and hard macros (eg memory generators).  Their initial run is
aimed for a multi-platform wafer service.

> >>> I have to ask: why spend time hacking x86 when there are so many other,
> >>> BETTER architectures out there? :)
> >>
> >> I have a long history on 80386.  I wrote my own kernel, debuggers, etc.
> >> It's been a relationship dating back to the late 80s.
> >
> > Oh, ok.

There is an argument that the i386 has the largest software stack, so an
i386 will have the most compatibility.  However, that is changing.  The
Linux kernel doesn't support the i386 any more.  Many binaries end up using
MMX, SSE and so on, so won't work on an i386.  Other operating systems are
more platform agnostic (eg Android runs on ARM, x86, MIPS and others).

Maybe that doesn't matter to you, but the question is not just what is the
best choice now, but what might be when the you hope to be finished.

One useful feature of RISC-V is they have ISA subsets: the base RV32I subset
is quite small, and then features like 64 bit, floating point, etc are
extra.  That means the instruction requirements of software are made
explicit.

> It will never be possible to include an ARM ISA unless a license fee is 
> paid.  I recall some years back a student produced an HDL version of an 
> ARM 7TDMI.  ARM spoke to him and the core was withdrawn.  He also got a 
> job with them.  Win/win

ARMv2 (ARM with 26 bit addressing) is now out of patent, so it's possible to
implement it licence-free, and it has been:
https://en.wikipedia.org/wiki/Amber_(processor_core)

That is one thing in favour of the i386 against newer architectures: it is
now out of patent, so Intel can't sue you for making one.

> 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.

We've also designed our own 64-bit CPUs, with our own ISA extensions. 
Multicore and cache coherency were a significant effort, likewise we spend a
lot of effort on testing.

Software is indeed a lot of work, though using the maximum of pre-existing
software helps.

> > At any rate, this implementation is an absolute MONSTER, clocking in at
> > 36k gates (and providing a passe 30 MHz of x86). Just how the fuck am I
> > supposed to fit that in a sane chip? You know, the ones for which you can
> > get synthesizers for free, instead of paying several thousand dollars for
> > them.

This is the tricky question about the 'homebrew silicon fab' question.

I think there's an interesting space for the 'artisanal semiconductor fab',
that makes old chips relatively cheaply and allows users to get closer to
the process.  Some universities have that kind of facility, but often not
intended for even medium volume manufacturing.  But a general
democratisation of fab technology could be an interesting space.

You'd think that using new techniques on an old process would make life
easier, just like people can make marble sculpture with CNC machines instead
of hammers.

What hits you, however, is lack of Moore's law.  Let's say you have a 3
micron fab.  You might only have two metal layers.  You just can't get many
transistors on that chip, and you can't wire them very well.  The tools
aren't optimised for that kind of environment, and will waste space trying
to deal with layer limitations.  You also can't fit much memory, and you
can't deal with modern interfaces (no USB for you) or modern off-chip DRAM.

You'd end up with 1970s style hand design, albeit with a fancy GUI rather
than plastic tapes, connected to 1970s peripherals.

Maybe you can deal with some of those by careful choice of off-chip
components (eg everything is SRAM, not DDR4) and others by die stacking a
commodity small-process interface die on top of your large-process die. 

Maybe the 'artisanal' producer makes the coarse-grained silicon interposer,
and then stacks commodity dice from other vendors on it - like hobbyists make
and assemble PCBs today.  It does, however, require an ecosystem set up for
that.

Theo

Article: 158801
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Sun, 10 Apr 2016 15:07:47 -0400
Links: << >>  << T >>  << A >>
On 4/10/2016 2:26 PM, Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>> I expect trying to get anything remotely like a critical mass is
>> virtually impossible.  There is an open source chip similar in size and
>> capability to the ARM processors called RISC-V that is getting wide
>> attention and will produce a chip soon.
>
> RISC-V is an architecture, and various chips have been produced.  It's also
> getting embedded in other products (eg as a tiny part of some other SoC).
>
> My colleagues at LowRISC:
> http://www.lowrisc.org/
>
> are working on a fully open-source SoC based on the RISC-V architecture - ie
> open source at the Verilog design level, including peripheral IP.  They
> still face many challenges, including the need to use proprietary
> ASIC tools and hard macros (eg memory generators).  Their initial run is
> aimed for a multi-platform wafer service.
>
>>>>> I have to ask: why spend time hacking x86 when there are so many other,
>>>>> BETTER architectures out there? :)
>>>>
>>>> I have a long history on 80386.  I wrote my own kernel, debuggers, etc.
>>>> It's been a relationship dating back to the late 80s.
>>>
>>> Oh, ok.
>
> There is an argument that the i386 has the largest software stack, so an
> i386 will have the most compatibility.  However, that is changing.  The
> Linux kernel doesn't support the i386 any more.  Many binaries end up using
> MMX, SSE and so on, so won't work on an i386.  Other operating systems are
> more platform agnostic (eg Android runs on ARM, x86, MIPS and others).
>
> Maybe that doesn't matter to you, but the question is not just what is the
> best choice now, but what might be when the you hope to be finished.
>
> One useful feature of RISC-V is they have ISA subsets: the base RV32I subset
> is quite small, and then features like 64 bit, floating point, etc are
> extra.  That means the instruction requirements of software are made
> explicit.
>
>> It will never be possible to include an ARM ISA unless a license fee is
>> paid.  I recall some years back a student produced an HDL version of an
>> ARM 7TDMI.  ARM spoke to him and the core was withdrawn.  He also got a
>> job with them.  Win/win
>
> ARMv2 (ARM with 26 bit addressing) is now out of patent, so it's possible to
> implement it licence-free, and it has been:
> https://en.wikipedia.org/wiki/Amber_(processor_core)
>
> That is one thing in favour of the i386 against newer architectures: it is
> now out of patent, so Intel can't sue you for making one.

I don't think the restriction was ever patent based.  It was a matter of 
microcode copyright.  That is why AMD had to use cleanrooms to generate 
a spec for all subsequent CPUs they desired to copy.  That gets around 
copyright.  So the 386 doesn't have an advantage over other x86 
processors in terms of IP protection while it does have an advantage 
over patent protected designs.


>> 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.
>
> We've also designed our own 64-bit CPUs, with our own ISA extensions.
> Multicore and cache coherency were a significant effort, likewise we spend a
> lot of effort on testing.
>
> Software is indeed a lot of work, though using the maximum of pre-existing
> software helps.
>
>>> At any rate, this implementation is an absolute MONSTER, clocking in at
>>> 36k gates (and providing a passe 30 MHz of x86). Just how the fuck am I
>>> supposed to fit that in a sane chip? You know, the ones for which you can
>>> get synthesizers for free, instead of paying several thousand dollars for
>>> them.
>
> This is the tricky question about the 'homebrew silicon fab' question.
>
> I think there's an interesting space for the 'artisanal semiconductor fab',
> that makes old chips relatively cheaply and allows users to get closer to
> the process.  Some universities have that kind of facility, but often not
> intended for even medium volume manufacturing.  But a general
> democratisation of fab technology could be an interesting space.

I would like to see an open source effort for FPGAs.  I think the big 
roadblock would be the fab, but maybe it's more of a seed money issue 
since wafers can be bought for a reasonable price.  A *very* small 
startup created an array CPU on a shoestring a few years ago.  They have 
run a second batch of chips, so they must be selling them to someone. 
It's just a question of proving a market exists and coming up with the 
startup funding.

http://www.greenarraychips.com/

-- 

Rick

Article: 158802
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 11:06:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> Rick C. Hodgin wrote:
> > Rob Gaddi wrote:
> > > It's a bit of a pain as connectors go.
> > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language= English&CategoryNo=67&No=322&PartNo=1
> > > makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).
> > >
> > > --
> > > Rob Gaddi, Highland Technology
> > > www.highlandtechnology.com
> >
> > Thank you, Rob. That's exactly what I was looking for.
> Ordered. Thank you again.

Received.  Fits the board like it was made for it. :-)

Best regards,
Rick C. Hodgin

Article: 158803
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 11:12:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> I think you are better off not using the FPGA eval board and just
> making your own board with the 386 and the FPGA. The adapters
> and cables are going to add a lot of capacitance and noise
> to your signals. Why mess with the added complexity?

I'll need enough capacity to simulate my ISA, as well as drive the Am386.  They will more or less execute together, with off-device debugging signals to control operations.

Would the capacitance be an issue at a few hundred KHz max?  I plan to make the custom Am386 plug straight in to the three GPIO ports.

Best regards,
Rick C. Hodgin

Article: 158804
Subject: Re: Altera HSMC connector
From: Joe Chisolm <jchisolm6@earthlink.net>
Date: Mon, 11 Apr 2016 13:48:53 -0500
Links: << >>  << T >>  << A >>
On Mon, 11 Apr 2016 11:12:04 -0700, Rick C. Hodgin wrote:

> rickman wrote:
>> I think you are better off not using the FPGA eval board and just
>> making your own board with the 386 and the FPGA. The adapters and
>> cables are going to add a lot of capacitance and noise to your signals.
>> Why mess with the added complexity?
> 
> I'll need enough capacity to simulate my ISA, as well as drive the
> Am386.  They will more or less execute together, with off-device
> debugging signals to control operations.
> 
> Would the capacitance be an issue at a few hundred KHz max?  I plan to
> make the custom Am386 plug straight in to the three GPIO ports.
> 
> Best regards,
> Rick C. Hodgin

You may need to slow down the Cyclone IO edges.  If memory serves the
V has sub ns rise times.  Your cable and 386 input cap will help limit
that some.  Of course pay close attention to the setup and hold times
the 386 is going to require.

At one time PLX had local bus to pci chips.  I have not checked on them
lately.  They got bought by Avago some time back.  They may only do
PCIe now.



-- 
Chisolm
Republic of Texas


Article: 158805
Subject: Re: Altera HSMC connector
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Mon, 11 Apr 2016 18:55:09 -0000 (UTC)
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:

> Rick C. Hodgin wrote:
>> Rick C. Hodgin wrote:
>> > Rob Gaddi wrote:
>> > > It's a bit of a pain as connectors go.
>> > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language= English&CategoryNo=67&No=322&PartNo=1
>> > > makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).
>> > >
>> > > --
>> > > Rob Gaddi, Highland Technology
>> > > www.highlandtechnology.com
>> >
>> > Thank you, Rob. That's exactly what I was looking for.
>> Ordered. Thank you again.
>
> Received.  Fits the board like it was made for it. :-)
>
> Best regards,
> Rick C. Hodgin

I'm glad all the research effort I put in of looking
over at the stack of same sitting on the corner of my desk and
writing down the number from the box came in handy.

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

Article: 158806
Subject: Re: Altera HSMC connector
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Apr 2016 15:17:13 -0400
Links: << >>  << T >>  << A >>
On 4/11/2016 2:12 PM, Rick C. Hodgin wrote:
> rickman wrote:
>> I think you are better off not using the FPGA eval board and just
>> making your own board with the 386 and the FPGA. The adapters
>> and cables are going to add a lot of capacitance and noise
>> to your signals. Why mess with the added complexity?
>
> I'll need enough capacity to simulate my ISA, as well as drive the Am386.  They will more or less execute together, with off-device debugging signals to control operations.
>
> Would the capacitance be an issue at a few hundred KHz max?  I plan to make the custom Am386 plug straight in to the three GPIO ports.

You won't have trouble with lines that are essentially data lines, you 
don't care if they ring.  The trouble will be with clock like lines. 
That will include the actual clock and potentially the read/write 
strobes depending on how you implement the interface circuit.

More importantly, you may have trouble with ground bounce.  I've put my 
scope on the far end of disk drive ribbon cables before and the noise on 
the ground can be horrendous.

The issue is not the clock rate, it is the edge rate.  You can configure 
the FPGA for slower edge rates, but you can't do anything about the 386 
edge rates.  Running 100+ signal lines over a ribbon cable is just not a 
good idea unless you use differential signalling.  You may get away with 
it, you may not.  Since you are building a custom board anyway, why not 
just include the FPGA?

The other way to do this is to use a set of bidirectional 
latches/buffers and let the FPGA access the interface via a simple 
serial interface using LVDS signalling.  The FPGA already includes this 
functionallity.  You just need to add a few interface chips to the 386 
board along with your quickswitch devices.

-- 

Rick

Article: 158807
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 14:13:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:
> I'm glad all the research effort I put in of looking over at the
> stack of same sitting on the corner of my desk and writing down the
> number from the box came in handy.

Me too! :-)

Nonetheless, and regardless of how trivial the effort was, it got me
exactly what I needed, and it was/is appreciated.

Best regards,
Rick C. Hodgin

Article: 158808
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 14:23:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> The issue is not the clock rate, it is the edge rate. You can configure
> the FPGA for slower edge rates, but you can't do anything about the
> 386 edge rates. Running 100+ signal lines over a ribbon cable is just not
> a good idea unless you use differential signalling. You may get
> away with it, you may not. Since you are building a custom board
> anyway, why not just include the FPGA?

The board I intend to build will have three female mates to the
three male GPIO interface ports on the HSMC adapter card.  It will
plug straight into it.  No ribbon cables.  Just a direct connection.

As I understand it, the level shifters will introduce a delay, which should
not be an issue at much slower clock rates.

I do intend to build a direct coupling board.  I could envision also a
second FPGA on it for some purpose.  Not sure what that would be, but
I could see it.

BTW, my goals are not to have 30 year old technology, but rather to
start somewhere.  I am familiar with 386, it is ubiquitous, and it's
easily extensible.

I look forward to LibSF 386-x40 coming to life.

Best regards,
Rick C. Hodgin

Article: 158809
Subject: Re: Altera HSMC connector
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Apr 2016 18:28:35 -0400
Links: << >>  << T >>  << A >>
On 4/11/2016 5:23 PM, Rick C. Hodgin wrote:
> rickman wrote:
>> The issue is not the clock rate, it is the edge rate. You can configure
>> the FPGA for slower edge rates, but you can't do anything about the
>> 386 edge rates. Running 100+ signal lines over a ribbon cable is just not
>> a good idea unless you use differential signalling. You may get
>> away with it, you may not. Since you are building a custom board
>> anyway, why not just include the FPGA?
>
> The board I intend to build will have three female mates to the
> three male GPIO interface ports on the HSMC adapter card.  It will
> plug straight into it.  No ribbon cables.  Just a direct connection.

That's better, but the issue is as much the length as it is how the 
connection is made.  I suppose there will be many ground connections on 
all of the sockets?  Signal integrity is key.


> As I understand it, the level shifters will introduce a delay, which should
> not be an issue at much slower clock rates.

If you use the quickswitch parts you get less than a nanosecond delay. 
They aren't buffers, they are transmission gates that limit the voltage 
range on the 3.3 volt side.


> I do intend to build a direct coupling board.  I could envision also a
> second FPGA on it for some purpose.  Not sure what that would be, but
> I could see it.

Lol, if you don't know the purpose, that's not very good vision.  Try 
focusing on the things you can see clearly.  Normally a goal is in mind, 
then the path is selected to reach a number of smaller goals on the way 
to the main goal.  You seem to be plotting a path without clear 
objectives.


> BTW, my goals are not to have 30 year old technology, but rather to
> start somewhere.  I am familiar with 386, it is ubiquitous, and it's
> easily extensible.
>
> I look forward to LibSF 386-x40 coming to life.

Good luck.

-- 

Rick

Article: 158810
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 16:13:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> > I do intend to build a direct coupling board. I could envision also a
> > second FPGA on it for some purpose. Not sure what that would be, but
> > I could see it.
>
> Lol, if you don't know the purpose, that's not very good vision.

I don't know the purpose because it's your suggestion.  Mine is to
use my dev board.  It's been my plan all along.  It's why I bought it,
for my LibSF 386-x40 CPU design.

> Try focusing on the things you can see clearly. Normally a goal is in
> mind, then the path is selected to reach a number of smaller
> goals on the way to the main goal.

Ah:

    https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
    http://www.libsf.org/li386/indexmain.html 
    https://m.facebook.com/groups/726083540851343?view=info 

> You seem to be plotting a path without clear objectives.

You seem to see things incorrectly, and always disparaging toward me.

Best regards,
Rick C. Hodgin

Article: 158811
Subject: Re: Altera HSMC connector
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Apr 2016 00:22:23 +0100 (BST)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> That's better, but the issue is as much the length as it is how the 
> connection is made.  I suppose there will be many ground connections on 
> all of the sockets?  Signal integrity is key.

Assuming this is the standard Altera/Terasic 40 way pinout, there aren't. 
There's two ground, one 3.3V and one 5V per socket, at roughly 1/3 2/3
positioning.  The rest is GPIO.  You might get away with purposefully
grounding some GPIOs at the other end, but if Rick needs ~100 IOs there
aren't many to play with.  Each socket has (if I remember) 34 I/Os and two
clock inputs.

On the other hand, we get away with driving 40MHz video signals over ribbon
cable with that connector so there is some leeway.  YMMV of course.

Theo

Article: 158812
Subject: Re: Altera HSMC connector
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Apr 2016 19:50:54 -0400
Links: << >>  << T >>  << A >>
On 4/11/2016 7:13 PM, Rick C. Hodgin wrote:
> rickman wrote:
>>> I do intend to build a direct coupling board. I could envision also a
>>> second FPGA on it for some purpose. Not sure what that would be, but
>>> I could see it.
>>
>> Lol, if you don't know the purpose, that's not very good vision.
>
> I don't know the purpose because it's your suggestion.  Mine is to
> use my dev board.  It's been my plan all along.  It's why I bought it,
> for my LibSF 386-x40 CPU design.
>
>> Try focusing on the things you can see clearly. Normally a goal is in
>> mind, then the path is selected to reach a number of smaller
>> goals on the way to the main goal.
>
> Ah:
>
>      https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
>      http://www.libsf.org/li386/indexmain.html
>      https://m.facebook.com/groups/726083540851343?view=info
>
>> You seem to be plotting a path without clear objectives.
>
> You seem to see things incorrectly, and always disparaging toward me.

That's the second time you have indicated you don't appreciate my 
comments.  I will refrain from posting.

-- 

Rick

Article: 158813
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 17:40:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> I will refrain from posting.

My loss.

Best regards,
Rick C. Hodgin

Article: 158814
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 11 Apr 2016 17:44:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
Theo Markettos wrote:
> ... if Rick needs ~100 IOs there aren't many to play with. Each socket
> has (if I remember) 34 I/Os and two clock inputs.

I need 92 GPIO pins.  The remaining 40 are Vcc, Vss, or not connected.

Best regards,
Rick C. Hodgin

Article: 158815
Subject: Re: Altera HSMC connector
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 12 Apr 2016 08:42:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, April 11, 2016 at 8:44:07 PM UTC-4, Rick C. Hodgin wrote:
> Theo Markettos wrote:
> > ... if Rick needs ~100 IOs there aren't many to play with. Each socket
> > has (if I remember) 34 I/Os and two clock inputs.
> 
> I need 92 GPIO pins.  The remaining 40 are Vcc, Vss, or not connected.

I began studying the 80386 data sheets last night.  There are only 19 control
pins which will be used in a 32-bit bus implementation that does not support
address pipelining.  And only 16 if a math-coprocessor is not used.  And only
14 if there isn't an arbitrated system bus.  The rest are 30 address pins, 32
data pins, and either Vcc, Vss, or not connected.

Of those 14 pins:

    1 is the clock signal

    4 are address byte enablers (32-bit writes, 1 pin
      per byte to read 8-bit, 16-bit, 24-bit, or 32-bit)

    4 define the bus cycle definition
    2 defines the bus control operation

    2 define interrupt, non-maskable interrupt

    1 is reset

It is an incredibly simple design.  The Intel 80386 manuals also define
timing for their 20 MHz to 33 MHz parts.  I'm assuming the Am386 would
follow similar protocols.

Edge timing appears to be 4 ns, so that will need slowed.  The rest
would seem to fall within the clock cycle timing, but requires a certain
amount of time to pass before the data on the pins is valid, typically
in 20 or less ns, and often 4, 6, or 7 or more ns.

Best regards,
Rick C. Hodgin

Article: 158816
Subject: Atmels product selector
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Thu, 14 Apr 2016 16:53:32 +0200
Links: << >>  << T >>  << A >>
I've tried to open the product search in the CPLD product category several 
times in the last few days. I wanted to know if they'd axe any of that product line. 
It (script?) did not complete loading. Sometimes I'd get the progress indicator
(blue dots, never completing), sometimes I got a maintenance notice. 
Is this happening to anyone else or is perhaps my system misconfigured? 


Article: 158817
Subject: Re: Atmels product selector
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Apr 2016 12:16:18 -0400
Links: << >>  << T >>  << A >>
On 4/14/2016 10:53 AM, Johann Klammer wrote:
> I've tried to open the product search in the CPLD product category several
> times in the last few days. I wanted to know if they'd axe any of that product line.
> It (script?) did not complete loading. Sometimes I'd get the progress indicator
> (blue dots, never completing), sometimes I got a maintenance notice.
> Is this happening to anyone else or is perhaps my system misconfigured?

Got a link?

-- 

Rick

Article: 158818
Subject: Re: Atmels product selector
From: rickman <gnuarm@gmail.com>
Date: Thu, 14 Apr 2016 12:52:29 -0400
Links: << >>  << T >>  << A >>
On 4/14/2016 12:16 PM, rickman wrote:
> On 4/14/2016 10:53 AM, Johann Klammer wrote:
>> I've tried to open the product search in the CPLD product category
>> several
>> times in the last few days. I wanted to know if they'd axe any of that
>> product line.
>> It (script?) did not complete loading. Sometimes I'd get the progress
>> indicator
>> (blue dots, never completing), sometimes I got a maintenance notice.
>> Is this happening to anyone else or is perhaps my system misconfigured?
>
> Got a link?

I got Atmel mixed up with Altera.  I forgot Atmel made programmable 
logic.  lol

Yes, I see the same thing.  Under some other sections the Product Search 
does the same thing.  Under MCUs it loads normally.

-- 

Rick

Article: 158819
Subject: Re: Atmels product selector
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 14 Apr 2016 14:42:27 -0400
Links: << >>  << T >>  << A >>
Johann Klammer wrote:
> I've tried to open the product search in the CPLD product category several 
> times in the last few days. I wanted to know if they'd axe any of that product line. 
> It (script?) did not complete loading. Sometimes I'd get the progress indicator
> (blue dots, never completing), sometimes I got a maintenance notice. 
> Is this happening to anyone else or is perhaps my system misconfigured? 
> 
Might have changed since your initial post, but I see:


Maintenance Notice


The page you have requested is temporarily not available. Please check 
back later. We are sorry for any inconvenience.

If you go back to the page later, be sure to clear your browser's cache.

-- 
Gabor

Article: 158820
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 16 Apr 2016 07:58:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.  I
> want to be able to provide the features of the 80386 on that machine, but
> through my FPGA, to then allow me to extend the ISA to include other
> instructions and abilities.
> 
> Does anybody have an experience or advice in creating an FPGA-based CPU that
> connects to a real hardware device and simulates the real device's abilities?
> 
> For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
> 3.3V max, so I'd have to use a level converter.  At speeds up to a max of
> 40 MHz, would there be any issues?
> 
> Also, I'd like to create a "monitor board," which is a board with a 132-
> pin male socket connecting to the CPU on one side, and a 132-pin female
> socket on the other side to which a real 80386 CPU would connect, and then
> to be able to pull signals off the wires between the CPU socket and the
> CPU itself.  I had assumed I would use opto-isolation for this, but I don't
> know if it would work or be best.
> 
> In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
> that is 100% compatible with the Intel 80386, but it has the ability to
> underclock down to even 0 MHz in a standby mode (allowing it to consume
> only 0.001 Watts).  I'm wondering if anyone has any experience underclocking
> an 80386 motherboard down into the KHz range, or even Hz range, and if it
> would still work at those slow speeds on the board?
> 
> My goals in slowing down the CPU are to detect and isolate timing protocols,
> which I can then scale up to higher speeds once identified.
> 
> In any event, any help or advice is appreciated.  Thank you.

Well much to my surprise, I was watching CPU-related videos today and
I came across this video:

    https://www.youtube.com/watch?v=y0WEx0Gwk1E&t=4m22s

Beginning around 4:22 it shows the very type of board I was looking to
create to plug in to an existing 80386 system and monitor its signals.

Does anyone have one of these types boards on their shelf from back in
the day?

Best regards,
Rick C. Hodgin

Article: 158821
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Herbert Kleebauer <klee@unibwm.de>
Date: Sat, 16 Apr 2016 17:29:34 +0200
Links: << >>  << T >>  << A >>
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

But I doubt that a complete 386 will fit into a FPGA.



Article: 158822
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 16 Apr 2016 09:03:51 -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

How exciting! :-)

> But I doubt that a complete 386 will fit into a FPGA.

A man named Aleksander Osman has created a full 486SX CPU in an Altera
FPGA (Terasic DE2-115 only, and it does not have an FPU):

    https://github.com/alfikpl/ao486

It is comprised of:

    Unit               Cells    M9K
    ----------------   -----    ---
    ao486SX CPU        36517    47
    floppy             1514     2
    hdd                2071     17
    nios2              1056     3
    onchip for nios2   0 	    32
    pc_dma             848      0
    pic                388      0
    pit                667      0
    ps2                742      2
    rtc                783      1
    sound              37131    29
    vga                2534     260
    -------------------------------
    Total:             84,251   393

After compiling with Quartus II:

-----[ Start ]----
    Fitter Status : Successful - Sun Mar 30 21:00:13 2014
    Quartus II 64-Bit Version : 13.1.0 Build 162 10/23/2013 SJ Web Edition
    Revision Name : soc
    Top-level Entity Name : soc
    Family : Cyclone IV E
    Device : EP4CE115F29C7
    Timing Models : Final
    Total logic elements : 91,256 / 114,480 ( 80 % )
        Total combinational functions : 86,811 / 114,480 ( 76 % )
        Dedicated logic registers : 26,746 / 114,480 ( 23 % )
    Total registers : 26865
    Total pins : 108 / 529 ( 20 % )
    Total virtual pins : 0
    Total memory bits : 2,993,408 / 3,981,312 ( 75 % )
    Embedded Multiplier 9-bit elements : 44 / 532 ( 8 % )
    Total PLLs : 1 / 4 ( 25 % )
-----[ End ]----

Runs at 39 MHz.  Boots and runs:

    Microsoft MS-DOS version 6.22
    Microsoft Windows for Workgroups 3.11
    Microsoft Windows 95
    Linux 3.13.1

Best regards,
Rick C. Hodgin

Article: 158823
Subject: VHDL Obfuscators, the Good, the Bad, and the Ugly
From: email.crj@gmail.com
Date: Thu, 21 Apr 2016 06:27:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have been looking at the various options for VHDL obfuscators.  I have tried all of the free programs that I could find and was left unimpressed.  I also has similar unimpressive results with a demo version of a commercial program.  

The best results were from some test code run through the VISENGI commercial program, but they do not have a demo version, so I can't make a full evaluation.

Before I make the final decision, does anyone have positive (or negative) experiences to relate about VHDL obfuscators in general and the VISENGI obfuscator in particular?

Thanks,
Chris Johnson

Article: 158824
Subject: Re: VHDL Obfuscators, the Good, the Bad, and the Ugly
From: HT-Lab <hans64@htminuslab.com>
Date: Thu, 21 Apr 2016 16:52:32 +0100
Links: << >>  << T >>  << A >>
On 21/04/2016 14:27, email.crj@gmail.com wrote:
> I have been looking at the various options for VHDL obfuscators.  I have tried all of the free programs that I could find and was left unimpressed.  I also has similar unimpressive results with a demo version of a commercial program.
>
> The best results were from some test code run through the VISENGI commercial program, but they do not have a demo version, so I can't make a full evaluation.
>
> Before I make the final decision, does anyone have positive (or negative) experiences to relate about VHDL obfuscators in general and the VISENGI obfuscator in particular?
>
> Thanks,
> Chris Johnson
>
Hi Chris,

Personally I would bother with obfuscation as it is relative easy to 
de-obfuscate the code even if they change the signal names through each 
port map. If you really want to obfuscate your RTL then I would suggest 
getting hold of a synthesis tool that can write out an RTL netlist (like 
Leonardo Spectrum). You can then target a very simple device like a CPLD 
which doesn't have any complex modgens. You won't get better obfuscation 
than a netlist full of gates and FF's.

You could also look into VHDL2008 encryption which is OK for simulation 
but a different story if you want reach the bitstream,

Good luck,
Hans
www.ht-lab.com



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