this post was submitted on 12 Nov 2023
99 points (93.0% liked)

Technology

58303 readers
11 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
 

It could be the key to making tomorrow’s smart tech sustainable.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Right, apologies for dumping it down so far, I find it hard to properly gauge the knowledge of others on the internet, and just try and play safe.

I wasn't aware that one could serial program gate arrays, as, as far as I know, the definition of serial programming is code that is governed by a processor, and which prohibits anything but serial execution of commands. So it's new to me that gate arrays can run serial code without any governance or serialization process, since gate arrays by themselves are anything but serial. Or rather, you need to synchronize anything and everything that is supposed to be serial by yourself, or use pre-built and pre-synced blocks, I guess.

Anyway, going by the definition that serial programming can only be performed using some kind of governance or synchronizing authority, that alone would be another layer of security.

As serial implies, it rid us, or lessened the burden, of those timing related issues, some of which included:

  • All the problems of accessing in-use resources that multi-cored serial "parallel" programming reintroduced.
  • Making a block and not properly timing it resulting in the clock changing while it's still flipping gates and produce unexpected behavior.
  • As the above, just generally having to time everything, as having too many clock blocks or sync checks results in unnecessary speed loss, and having too few checks might result in unexpected behavior.
  • Over/underclocking and other slight power and clock variations.
  • Uninitialized gates producing random behavior.
  • And by extension: the power up process not being exactly the same every time, resulting in more unexpected behavior. Very annoying to debug when it looks all right to start with.
  • Reading through seconds of timing diagrams (that's a lot of reading with a clock time of nano seconds).
  • Block placement and connection problems.
  • Using gate array layouts/code with differing transistor specs.

And the list goes on, but you know.

Serial also has a lot of pitfalls, and you can definitely screw things up bad, but at least you don't have to think much about clock or timing, or memory placement, unless communicating between devices or cores, and those sync problems tend to be rather tame and simple compared to intra-processor problems.

At least from my experience.

[–] [email protected] 1 points 1 year ago

Oh if serial programming is not a thing in the electronics low level realm, then all is well. It's not news. It just doesn't exist. Apologies. I just assumed it was a thing since you said "parallel programming comes with almost no safety," and in my eyes, that implied that there existed other kinds of programming besides parallel in the context you were referring to.