S
server
Guest
message unavailable
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
A
Anton T.
Guest
El martes, 14 de agosto de 2001 a la(s) 09:47:18 UTC-5, Gary Cho escribió:
I know it\'s been almost a decade since this was first published, but I, a non-engineer with no experience whatsoever in electronics, would like to build one myself. Were you successful in this project?
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
I know it\'s been almost a decade since this was first published, but I, a non-engineer with no experience whatsoever in electronics, would like to build one myself. Were you successful in this project?
T
Tom Del Rosso
Guest
Anton T. wrote:
It\'s been 2 decades, and I\'m sure he wasn\'t. Even 19 years ago the bus
speeds required software costing many thousands to compute the trace
characteristics.
El martes, 14 de agosto de 2001 a la(s) 09:47:18 UTC-5, Gary Cho
escribió:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is
out of curiosity and self challenge. Personally I have some
experience building simple embedded systems but a x86 motherboard
would be very challenging indeed. Objective here it to learn from
hands on experience. If anyone is interested in such project, we can
work together in designing it. E-mail me.
I know it\'s been almost a decade since this was first published, but
I, a non-engineer with no experience whatsoever in electronics, would
like to build one myself. Were you successful in this project?
It\'s been 2 decades, and I\'m sure he wasn\'t. Even 19 years ago the bus
speeds required software costing many thousands to compute the trace
characteristics.
R
Ricketty C
Guest
On Tuesday, October 20, 2020 at 11:24:48 AM UTC-4, Tom Del Rosso wrote:
I seem to recall that was about the time of higher speed memory which did require careful attention to signal integrity issues which was new to the PC industry with resultantly poor results from some manufacturers. Memory errors were commonly blamed on \"poor\" memory modules with users switching them around trying to find the \"right\" combination. The reality was they were simply modifying the reflections of the poor motherboard designs allowing the memory bus to work a little more often or a little less often.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
Anton T. wrote:
El martes, 14 de agosto de 2001 a la(s) 09:47:18 UTC-5, Gary Cho
escribió:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is
out of curiosity and self challenge. Personally I have some
experience building simple embedded systems but a x86 motherboard
would be very challenging indeed. Objective here it to learn from
hands on experience. If anyone is interested in such project, we can
work together in designing it. E-mail me.
I know it\'s been almost a decade since this was first published, but
I, a non-engineer with no experience whatsoever in electronics, would
like to build one myself. Were you successful in this project?
It\'s been 2 decades, and I\'m sure he wasn\'t. Even 19 years ago the bus
speeds required software costing many thousands to compute the trace
characteristics.
I seem to recall that was about the time of higher speed memory which did require careful attention to signal integrity issues which was new to the PC industry with resultantly poor results from some manufacturers. Memory errors were commonly blamed on \"poor\" memory modules with users switching them around trying to find the \"right\" combination. The reality was they were simply modifying the reflections of the poor motherboard designs allowing the memory bus to work a little more often or a little less often.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
B
Bill Sloman
Guest
On Wednesday, October 21, 2020 at 2:24:48 AM UTC+11, Tom Del Rosso wrote:
They didn\'t. The problem was that the then standard computer buses weren\'t designed to work as terminated transmission lines.
Emitter-coupled logic had always been fast enough that it was designed to drive terminated transmission lines, and LVDS - low voltage digital signalling - essentially stuck with the approach of keeping the signal levels low enough to allow for resistive termination with small resistors that generated only tolerable amounts of heat that could be dissipated locally.
If you stuck to LVDS signalling, laying out the bus is pretty straight-forward, but when I last did it, I needed lots of buffers between the memory chips and the bus. Some programmable gate arrays had started offering LVDS compatible inputs and outputs, but - back then (1997-98) they were very expensive.
Some ten years earlier I\'d been able to buy ECL static RAM, but by 1998, it wasn\'t commercially available - too useful for very fast military radar systems.
--
Bill Sloman, Sydney
Anton T. wrote:
El martes, 14 de agosto de 2001 a la(s) 09:47:18 UTC-5, Gary Cho
escribió:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is
out of curiosity and self challenge. Personally I have some
experience building simple embedded systems but a x86 motherboard
would be very challenging indeed. Objective here it to learn from
hands on experience. If anyone is interested in such project, we can
work together in designing it. E-mail me.
I know it\'s been almost a decade since this was first published, but
I, a non-engineer with no experience whatsoever in electronics, would
like to build one myself. Were you successful in this project?
It\'s been 2 decades, and I\'m sure he wasn\'t. Even 19 years ago the bus
speeds required software costing many thousands to compute the trace
characteristics.
They didn\'t. The problem was that the then standard computer buses weren\'t designed to work as terminated transmission lines.
Emitter-coupled logic had always been fast enough that it was designed to drive terminated transmission lines, and LVDS - low voltage digital signalling - essentially stuck with the approach of keeping the signal levels low enough to allow for resistive termination with small resistors that generated only tolerable amounts of heat that could be dissipated locally.
If you stuck to LVDS signalling, laying out the bus is pretty straight-forward, but when I last did it, I needed lots of buffers between the memory chips and the bus. Some programmable gate arrays had started offering LVDS compatible inputs and outputs, but - back then (1997-98) they were very expensive.
Some ten years earlier I\'d been able to buy ECL static RAM, but by 1998, it wasn\'t commercially available - too useful for very fast military radar systems.
--
Bill Sloman, Sydney
B
Bill Sloman
Guest
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
--
Bill Sloman, Sydney
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
--
Bill Sloman, Sydney
R
Ricketty C
Guest
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
The latency of USB is too high for a practical memory interface. Perhaps you meant mass storage or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os. This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA. Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home? Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience..
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved..
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface. Perhaps you meant mass storage or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os. This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA. Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home? Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
B
Bill Sloman
Guest
On Wednesday, October 21, 2020 at 5:15:17 PM UTC+11, Ricketty C wrote:
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
> Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
> or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectaculary fast
https://en.wikipedia.org/wiki/USB-C
so you might be able to get away with an affordable amount of cache RAM on-chip.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Ho hum.
--
Bill Sloman, Sydney
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface.
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
> Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
> or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectaculary fast
https://en.wikipedia.org/wiki/USB-C
so you might be able to get away with an affordable amount of cache RAM on-chip.
This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home? Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
Ho hum.
--
Bill Sloman, Sydney
R
Ricketty C
Guest
On Wednesday, October 21, 2020 at 3:21:00 AM UTC-4, Bill Sloman wrote:
Yep, read it, processed it and realized it was wrong for the reason I stated, latency.
Ah, I interpreted that confusing term as main memory.
The issue is not speed, but latency. Perhaps you didn\'t fully process what I wrote.
> so you might be able to get away with an affordable amount of cache RAM on-chip.
\"Affordable\" is the key term. \"Affordable\" FPGAs don\'t have GBs of RAM on chip, at least not available as useful memory. Cache, perhaps, but main memory will still be external to the FPGA over a high speed bus with minimal latency. Have you read anything about the speeds and operation of DRAM these days?
Probably not the best place to search, although there is one fellow, can\'t recall his name just now, who has a compendium of MCU cores with performance specs. He has actually built and run a number of them. I don\'t recall anything in the list that would be anything like a full fledged PC CPU although some are quite capable.
Indeed. One thing Larkin is right about is that you primarily come here to argue with people about pretty much everything and nothing. There are many opportunities to have fruitful conversations on many topics. No need to always focus on disputing every detail of every post.
It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
On Wednesday, October 21, 2020 at 5:15:17 PM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface.
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
Yep, read it, processed it and realized it was wrong for the reason I stated, latency.
Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
Ah, I interpreted that confusing term as main memory.
or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectaculary fast
https://en.wikipedia.org/wiki/USB-C
The issue is not speed, but latency. Perhaps you didn\'t fully process what I wrote.
> so you might be able to get away with an affordable amount of cache RAM on-chip.
\"Affordable\" is the key term. \"Affordable\" FPGAs don\'t have GBs of RAM on chip, at least not available as useful memory. Cache, perhaps, but main memory will still be external to the FPGA over a high speed bus with minimal latency. Have you read anything about the speeds and operation of DRAM these days?
This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Probably not the best place to search, although there is one fellow, can\'t recall his name just now, who has a compendium of MCU cores with performance specs. He has actually built and run a number of them. I don\'t recall anything in the list that would be anything like a full fledged PC CPU although some are quite capable.
Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home? Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
Ho hum.
Indeed. One thing Larkin is right about is that you primarily come here to argue with people about pretty much everything and nothing. There are many opportunities to have fruitful conversations on many topics. No need to always focus on disputing every detail of every post.
It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
B
Bill Sloman
Guest
On Thursday, October 22, 2020 at 4:33:22 AM UTC+11, Ricketty C wrote:
There\'s going to be latency in the link inside the programmable logic device?
Strange. I\'d already said that the programmable logic device should have room for random access memory, which yo should have recognised as \"main memory\".
Perhaps you don\'t understand where latency comes from? Any modern serial link processes data in packets, so there\'s a latency implied in the length of the packet, but it is a function of the speed of the link.
Rotating memory has a latency that come from the data only becoming available once per rotation of the media - 7200 rpm implies a maxi,um wait of 8.3 msec. It doesn\'t stop hard disks being a useful form of memory.
Whenever I think about buying more of it.
So what would be a better place to start searching?
> > > Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home?
That wasn\'t what the original poster was asking for.
So your unspecific claim about \"latency\" was constructive?
> It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
At the moment there\'s still a lot more computing power between even Larkin\'s ears than you could buy anywhere. It isn\'t fast but it is massively parallel - 86 billion neurones worth of it. Getting it properly programmed is a challenge.
https://www.frontiersin.org/articles/10.3389/neuro.09.031.2009/full
--
Bill Sloman, Sydney
On Wednesday, October 21, 2020 at 3:21:00 AM UTC-4, Bill Sloman wrote:
On Wednesday, October 21, 2020 at 5:15:17 PM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface.
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
Yep, read it, processed it and realized it was wrong for the reason I stated, latency.
There\'s going to be latency in the link inside the programmable logic device?
Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
Ah, I interpreted that confusing term as main memory.
Strange. I\'d already said that the programmable logic device should have room for random access memory, which yo should have recognised as \"main memory\".
or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectacularly fast
https://en.wikipedia.org/wiki/USB-C
The issue is not speed, but latency. Perhaps you didn\'t fully process what I wrote.
Perhaps you don\'t understand where latency comes from? Any modern serial link processes data in packets, so there\'s a latency implied in the length of the packet, but it is a function of the speed of the link.
Rotating memory has a latency that come from the data only becoming available once per rotation of the media - 7200 rpm implies a maxi,um wait of 8.3 msec. It doesn\'t stop hard disks being a useful form of memory.
so you might be able to get away with an affordable amount of cache RAM on-chip.
\"Affordable\" is the key term. \"Affordable\" FPGAs don\'t have GBs of RAM on chip, at least not available as useful memory. Cache, perhaps, but main memory will still be external to the FPGA over a high speed bus with minimal latency. Have you read anything about the speeds and operation of DRAM these days?
Whenever I think about buying more of it.
This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Probably not the best place to search, although there is one fellow, can\'t recall his name just now, who has a compendium of MCU cores with performance specs. He has actually built and run a number of them. I don\'t recall anything in the list that would be anything like a full fledged PC CPU although some are quite capable.
So what would be a better place to start searching?
> > > Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home?
That wasn\'t what the original poster was asking for.
Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
Ho hum.
Indeed. One thing Larkin is right about is that you primarily come here to argue with people about pretty much everything and nothing. There are many opportunities to have fruitful conversations on many topics. No need to always focus on disputing every detail of every post.
So your unspecific claim about \"latency\" was constructive?
> It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
At the moment there\'s still a lot more computing power between even Larkin\'s ears than you could buy anywhere. It isn\'t fast but it is massively parallel - 86 billion neurones worth of it. Getting it properly programmed is a challenge.
https://www.frontiersin.org/articles/10.3389/neuro.09.031.2009/full
--
Bill Sloman, Sydney
R
Ricketty C
Guest
On Wednesday, October 21, 2020 at 11:08:28 PM UTC-4, Bill Sloman wrote:
USB is designed to be a party line. While you can get high data rates and dedicated bandwidth, it is not set up to be a memory interface. It has inherent latencies. But you were talking about mass storage which is not so sensitive to latency.
The interface to memory is what it is because that is what works properly. Even internal flash drives don\'t use USB for an interface because other interfaces are faster and better. USB has compromises to facilitate hot swapping and sharing interfaces. If USB were optimal for Flash they would not have invented yet another interface.
I\'ve never seen anyone mix the terms mass and memory. Mass storage or various memories, not mass memory. Your statements about main memory are also wrong unless you are talking about machines from the 1990s.
Now you seem to be confusing main memory with mass storage.
So that\'s a no or a yes? Regardless, you don\'t seem to understand either memory or FPGAs or perhaps both.
It\'s your hunt. You can ask in c.a.f. I ended up getting a response there to a VHDL question when no one responded in c.l.vhdl. Got a much better response in stackexchange from someone who used to post in newsgroups, but not so much anymore. It proved to be a good discussion because there was no consensus if I was violating the language or the simulator had a bug. The vendors are not very responsive to reporting bugs when you aren\'t under a maintenance contract, so it may never get fixed unless someone else also finds it and reports it.
Precisely. Exactly what I said. I am suggesting something I think is more fun. Is that not allowed?
What, you don\'t understand it? Do you understand the need for low latency in a main memory interface?
Apples and oranges. It is good at some jobs, like sorting apples and oranges. It\'s not so good at other tasks like predicting the path of an incoming missile to know if it is headed to Washington, DC or New York City. It is often not even very good a balancing a check book. I think the main issue with it is the lack of reliability. In many tasks that is a very important feature. Even 1 failure in 1,000 is not so good while we accept that from the vast majority of our mental processes.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
On Thursday, October 22, 2020 at 4:33:22 AM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 3:21:00 AM UTC-4, Bill Sloman wrote:
On Wednesday, October 21, 2020 at 5:15:17 PM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface.
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
Yep, read it, processed it and realized it was wrong for the reason I stated, latency.
There\'s going to be latency in the link inside the programmable logic device?
USB is designed to be a party line. While you can get high data rates and dedicated bandwidth, it is not set up to be a memory interface. It has inherent latencies. But you were talking about mass storage which is not so sensitive to latency.
The interface to memory is what it is because that is what works properly. Even internal flash drives don\'t use USB for an interface because other interfaces are faster and better. USB has compromises to facilitate hot swapping and sharing interfaces. If USB were optimal for Flash they would not have invented yet another interface.
Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
Ah, I interpreted that confusing term as main memory.
Strange. I\'d already said that the programmable logic device should have room for random access memory, which yo should have recognised as \"main memory\".
I\'ve never seen anyone mix the terms mass and memory. Mass storage or various memories, not mass memory. Your statements about main memory are also wrong unless you are talking about machines from the 1990s.
or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectacularly fast
https://en.wikipedia.org/wiki/USB-C
The issue is not speed, but latency. Perhaps you didn\'t fully process what I wrote.
Perhaps you don\'t understand where latency comes from? Any modern serial link processes data in packets, so there\'s a latency implied in the length of the packet, but it is a function of the speed of the link.
Rotating memory has a latency that come from the data only becoming available once per rotation of the media - 7200 rpm implies a maxi,um wait of 8.3 msec. It doesn\'t stop hard disks being a useful form of memory.
Now you seem to be confusing main memory with mass storage.
so you might be able to get away with an affordable amount of cache RAM on-chip.
\"Affordable\" is the key term. \"Affordable\" FPGAs don\'t have GBs of RAM on chip, at least not available as useful memory. Cache, perhaps, but main memory will still be external to the FPGA over a high speed bus with minimal latency. Have you read anything about the speeds and operation of DRAM these days?
Whenever I think about buying more of it.
So that\'s a no or a yes? Regardless, you don\'t seem to understand either memory or FPGAs or perhaps both.
This would be easy and fast with the FPGA memory constituting cache..
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Probably not the best place to search, although there is one fellow, can\'t recall his name just now, who has a compendium of MCU cores with performance specs. He has actually built and run a number of them. I don\'t recall anything in the list that would be anything like a full fledged PC CPU although some are quite capable.
So what would be a better place to start searching?
It\'s your hunt. You can ask in c.a.f. I ended up getting a response there to a VHDL question when no one responded in c.l.vhdl. Got a much better response in stackexchange from someone who used to post in newsgroups, but not so much anymore. It proved to be a good discussion because there was no consensus if I was violating the language or the simulator had a bug. The vendors are not very responsive to reporting bugs when you aren\'t under a maintenance contract, so it may never get fixed unless someone else also finds it and reports it.
Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home?
That wasn\'t what the original poster was asking for.
Precisely. Exactly what I said. I am suggesting something I think is more fun. Is that not allowed?
Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
Ho hum.
Indeed. One thing Larkin is right about is that you primarily come here to argue with people about pretty much everything and nothing. There are many opportunities to have fruitful conversations on many topics. No need to always focus on disputing every detail of every post.
So your unspecific claim about \"latency\" was constructive?
What, you don\'t understand it? Do you understand the need for low latency in a main memory interface?
It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
At the moment there\'s still a lot more computing power between even Larkin\'s ears than you could buy anywhere. It isn\'t fast but it is massively parallel - 86 billion neurones worth of it. Getting it properly programmed is a challenge.
https://www.frontiersin.org/articles/10.3389/neuro.09.031.2009/full
Apples and oranges. It is good at some jobs, like sorting apples and oranges. It\'s not so good at other tasks like predicting the path of an incoming missile to know if it is headed to Washington, DC or New York City. It is often not even very good a balancing a check book. I think the main issue with it is the lack of reliability. In many tasks that is a very important feature. Even 1 failure in 1,000 is not so good while we accept that from the vast majority of our mental processes.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
B
Bill Sloman
Guest
On Thursday, October 22, 2020 at 3:32:52 PM UTC+11, Ricketty C wrote:
Except that you don\'t specify what these latencies are.
> The interface to memory is what it is because that is what works properly.. Even internal flash drives don\'t use USB for an interface because other interfaces are faster and better. USB has compromises to facilitate hot swapping and sharing interfaces. If USB were optimal for Flash they would not have invented yet another interface.
Parallel interfaces are faster than serial interfaces. They also use more pins.
..> > > > > Perhaps you meant mass storage
What - exactly - was wrong with my statements about main memory? So far, you strike me as not knowing what you are talking about and hiding the fact by being picky about my word choices.
No. I was being specific about a particular form of \"latency\" which isn\'t something yo9u seem to be able to manage.
It was a yes. It seems you can only understand comments about memory when people use precisely the form of words that you are used to.
Not exactly. I suggested comp.arch.fpga and you don\'t seem to like it, but can\'t come up with anything specific that might be better.
It\'s quite a way from what the original poster seems to have had in mind.
If you can\'t put a number on the time delay involved, you clearly don\'t understand it any useful way.
There are mechanisms - double entry book-keeping is one of them - that add enough error-detection and correction to make data processing by human being pretty reliable.
I\'ve been doing a bit of it here.
--
Bill Sloman, Sydney
On Wednesday, October 21, 2020 at 11:08:28 PM UTC-4, Bill Sloman wrote:
On Thursday, October 22, 2020 at 4:33:22 AM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 3:21:00 AM UTC-4, Bill Sloman wrote:
On Wednesday, October 21, 2020 at 5:15:17 PM UTC+11, Ricketty C wrote:
On Wednesday, October 21, 2020 at 1:09:22 AM UTC-4, Bill Sloman wrote:
On Wednesday, August 15, 2001 at 12:47:18 AM UTC+10, Gary Cho wrote:
Hello All,
I am tempted to build a PC motherboard from the PCB level. This is out
of curiosity and self challenge. Personally I have some experience
building simple embedded systems but a x86 motherboard would be very
challenging indeed. Objective here it to learn from hands on experience.
If anyone is interested in such project, we can work together in
designing it. E-mail me.
This is probably the wrong project. Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory.
https://en.wikipedia.org/wiki/Field-programmable_gate_array
What you probably ought to do is buy one with enough USB-C ports to communicate with the mass memory and I/O ports that you would need.
Having a separate USB-C port for each of
1. Mass memory
2. Visual display
3. Keyboard
4. Printer
5,. Audio output
6. Audio input
7. Camera
8. Internet
would probably be an overkill, but I don\'t know enough about USB links to be to too confident about multiplexing them.
A package that had enough pins to deal with that and power supply would probably only need pins around the periphery of the package, making for a fairly simple layout, but it would probably still need a four layer board, and you might need to go for buried strip-lines to keep the connections from device to the USB-C sockets clean enough to handle the frequencies involved.
There\'s probably even a Linux -licensed design for the processor that would go inside the FPGA. There\'s even a user-group for people with those kinds of interests - comp.arch.fpga. Sometimes we used to get stuff cross-posted from there, but I can\'t recall anything recent..
The latency of USB is too high for a practical memory interface.
What I wrote - and you don\'t seem to have fully processed - was
\"Modern programmable logic devices can replicate all the hardware on a computer motherboard, including the random access memory\".
Yep, read it, processed it and realized it was wrong for the reason I stated, latency.
There\'s going to be latency in the link inside the programmable logic device?
USB is designed to be a party line. While you can get high data rates and dedicated bandwidth, it is not set up to be a memory interface. It has inherent latencies. But you were talking about mass storage which is not so sensitive to latency.
Except that you don\'t specify what these latencies are.
> The interface to memory is what it is because that is what works properly.. Even internal flash drives don\'t use USB for an interface because other interfaces are faster and better. USB has compromises to facilitate hot swapping and sharing interfaces. If USB were optimal for Flash they would not have invented yet another interface.
Parallel interfaces are faster than serial interfaces. They also use more pins.
..> > > > > Perhaps you meant mass storage
I explicitly listed \"mass storage\" as one of the USB-C ports the device would need.
Ah, I interpreted that confusing term as main memory.
Strange. I\'d already said that the programmable logic device should have room for random access memory, which you should have recognised as \"main memory\".
I\'ve never seen anyone mix the terms mass and memory. Mass storage or various memories, not mass memory. Your statements about main memory are also wrong unless you are talking about machines from the 1990s.
What - exactly - was wrong with my statements about main memory? So far, you strike me as not knowing what you are talking about and hiding the fact by being picky about my word choices.
or maybe you are talking about making a PC from 2000 where the main memory would only be measured in MBs, but even then... it would be a large and expensive FPGA to hold half a GB of RAM. But it is practical to hang main memory devices on FPGA I/Os.
That tends to take up a lot of pins. USB-C can be spectacularly fast
https://en.wikipedia.org/wiki/USB-C
The issue is not speed, but latency. Perhaps you didn\'t fully process what I wrote.
Perhaps you don\'t understand where latency comes from? Any modern serial link processes data in packets, so there\'s a latency implied in the length of the packet, but it is a function of the speed of the link.
Rotating memory has a latency that come from the data only becoming available once per rotation of the media - 7200 rpm implies a maxi,um wait of 8.3 msec. It doesn\'t stop hard disks being a useful form of memory.
Now you seem to be confusing main memory with mass storage.
No. I was being specific about a particular form of \"latency\" which isn\'t something yo9u seem to be able to manage.
so you might be able to get away with an affordable amount of cache RAM on-chip.
\"Affordable\" is the key term. \"Affordable\" FPGAs don\'t have GBs of RAM on chip, at least not available as useful memory. Cache, perhaps, but main memory will still be external to the FPGA over a high speed bus with minimal latency. Have you read anything about the speeds and operation of DRAM these days?
Whenever I think about buying more of it.
So that\'s a no or a yes? Regardless, you don\'t seem to understand either memory or FPGAs or perhaps both.
It was a yes. It seems you can only understand comments about memory when people use precisely the form of words that you are used to.
This would be easy and fast with the FPGA memory constituting cache.
I\'m sure people have built such machines. Heck they have simulated 8 bit controlled game machines that run much faster than the original. It seems like a huge amount of work to recreate a 2000 era PC on an FPGA.
That\'s why I suggested getting onto comp.arch.fpga and asking around.
Probably not the best place to search, although there is one fellow, can\'t recall his name just now, who has a compendium of MCU cores with performance specs. He has actually built and run a number of them. I don\'t recall anything in the list that would be anything like a full fledged PC CPU although some are quite capable.
So what would be a better place to start searching?
It\'s your hunt.
Not exactly. I suggested comp.arch.fpga and you don\'t seem to like it, but can\'t come up with anything specific that might be better.
You can ask in c.a.f. I ended up getting a response there to a VHDL question when no one responded in c.l.vhdl. Got a much better response in stackexchange from someone who used to post in newsgroups, but not so much anymore. It proved to be a good discussion because there was no consensus if I was violating the language or the simulator had a bug. The vendors are not very responsive to reporting bugs when you aren\'t under a maintenance contract, so it may never get fixed unless someone else also finds it and reports it.
Why not do something more interesting like find a way to optimize through parallelism tasks like SETI at home?
That wasn\'t what the original poster was asking for.
Precisely. Exactly what I said. I am suggesting something I think is more fun. Is that not allowed?
It\'s quite a way from what the original poster seems to have had in mind.
Well, looks like that one is no longer running. Maybe they\'ve already converted to FPGAs or even ASICs. At some point performing processing needs to account for the energy being consumed. That\'s why bit coin is no longer practical on PCs or even FPGAs. The energy costs are higher than the return for producing results.
So much silicon, so little time.
Ho hum.
Indeed. One thing Larkin is right about is that you primarily come here to argue with people about pretty much everything and nothing. There are many opportunities to have fruitful conversations on many topics. No need to always focus on disputing every detail of every post.
So your unspecific claim about \"latency\" was constructive?
What, you don\'t understand it? Do you understand the need for low latency in a main memory interface?
If you can\'t put a number on the time delay involved, you clearly don\'t understand it any useful way.
It is amazing how much computing power exists in the world. Sometimes I wonder how far we are from the singularity. Once it happens we will be so automated that it might not be much different from Terminator, says the guy with a self driving car!
At the moment there\'s still a lot more computing power between even Larkin\'s ears than you could buy anywhere. It isn\'t fast but it is massively parallel - 86 billion neurones worth of it. Getting it properly programmed is a challenge.
https://www.frontiersin.org/articles/10.3389/neuro.09.031.2009/full
Apples and oranges. It is good at some jobs, like sorting apples and oranges. It\'s not so good at other tasks like predicting the path of an incoming missile to know if it is headed to Washington, DC or New York City. It is often not even very good a balancing a check book. I think the main issue with it is the lack of reliability. In many tasks that is a very important feature. Even 1 failure in 1,000 is not so good while we accept that from the vast majority of our mental processes.
There are mechanisms - double entry book-keeping is one of them - that add enough error-detection and correction to make data processing by human being pretty reliable.
I\'ve been doing a bit of it here.
--
Bill Sloman, Sydney