[Coco] FPGA VS Software Emulators

[Dave Philipsen]

Actually you've attributed to me something that Mark actually wrote 
(below).  But, yes, parallelism is very do-able with an FPGA.  Just as a 
simple example, you could have ten completely different and separate 
circuits that would turn on an LED in response to some sort of input.  
Each logic section could run completely on its own with no other 
association with the others.  In theory, if you had enough logic 
elements you could create a design with multiple CPUs running in 
parallel.  In fact, Gary has a 6809 core *and* a 6502 core running on 
the same chip.

The MMU as it exists in the CoCo is really not that complicated of a 
device.  You have a CPU with 16 address lines and memory with, say, 19 
address lines.  You want granularity of 8K for the individual blocks so 
the bottom 13 lines of the CPU map straight out to the bottom 13 lines 
of the memory.  The upper 3 lines of the CPU then select eight different 
latches (defined in the FPGA) which contain preset values that will 
output to the upper three lines of the memory.  You create some I/O 
locations where the CPU can write the values to each of those eight 
latches.  (Actually there would be sixteen latches since the CoCo 3 has 
a task 1 MMU set and a task 2 MMU set).

Dave


On 7/26/2017 12:34 AM, Walter Zambotti wrote:
> Dave wrote:
>
>> So the input clock bears little hint as to the rate things are happening inside your device. eg the
>> above-mentioned examples with a 50MHz clock are actually running quite slowly (~25MHz) inside.
>> Contrast that with a design I've worked on with a 24MHz input clock; running logic at 150MHz and >DRAM at 4-500MHz...
> Leslie wrote:
>
>> At it's current top speed of 25MHz, that represents a 40ns cycle time.
>> Each cycle has a potential CPU and VIDEO access to the SRAMS, so the SRAMS are being accessed at no faster than 20ns at present.
> So to me it sounds as if the emulated CPU and GIME are functioning like real separate physical devices that require interleaving to the memory.
>
> That’s amazing!
>
> So even though there is just one FPGA unit the emulated CPU and the emulated GIME(GPU)  both behave as two separate devices!
>
> So they must run in parallel!
>
> I'll say it again, that's amazing!
>
> How much parallelism can occur in these FPGA devices?
>
> I suppose the down side is the maximum speed of the memory accesses will only be half as fast of what they could be!
>
> Walter
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Dave Philipsen
> Sent: Wednesday, 26 July 2017 12:45 PM
> To: coco at maltedmedia.com
> Subject: Re: [Coco] FPGA VS Software Emulators
>
> As Mark said, the 6809 core in the CoCo3FPGA runs at 25 MHz and the VGA dot clock is also conveniently 25 MHz.  Remember that the real CoCo 3 interleaves CPU access to the memory with video system access so I think it works out well when the CPU clock matches the dot clock in this case.
>
> And if anyone's interest has been piqued feel free to email me and I can send you an invitation to the CoCo3FPGA group.  You don't need to own an FPGA system to be a member; just a desire to snoop around and see what's going on over there.
>
> You can also go to: https://groups.yahoo.com/neo/groups/CoCo3FPGA/info
> and make a request for membership.
>
>
> Dave
>
>
> On 7/25/2017 7:45 PM, Mark McDougall wrote:
>> On 26/07/2017 10:30 AM, Mark McDougall wrote:
>>
>>>> Cyclone® IV EP4CE22F17C6N FPGA
>>>> runs at 50 MHz.
>>>> Altera Cyclone II 2C20 FPGA
>>>> runs at 50 MHz.
>> For those interested, the input clock to an FPGA is usually chosen
>> with regards to the desired clock frequencies inside the design. By
>> using multipliers and dividers FPGA PPLs have limits on the resolution
>> of generated frequencies, so if you have a particularly critical
>> frequency you need then you'd better make sure your input clock is a
>> "nice" frequency. There are even further constraints when generating
>> multiple frequencies from the one PLL (input clock), which is often
>> the case, and more-so again in smaller devices.
>>
>> Often parts of your design that don't have a specific frequency
>> requirement will run at a "convenient" frequency based on what the PLL
>> can output.
>>
>> So the input clock bears little hint as to the rate things are
>> happening inside your device. eg the above-mentioned examples with a
>> 50MHz clock are actually running quite slowly (~25MHz) inside.
>> Contrast that with a design I've worked on with a 24MHz input clock;
>> running logic at 150MHz and DRAM at 4-500MHz...
>>
>> Regards,
>>
>