<TD-Linux>
I made some comments about the win2k sprite system and the person who wrote it at microsoft corrected me
<hl>
oh god eSPI
<hl>
i'm dismayed to hear people are actually using that now
<whitequark>
TD-Linux: yes but you didn't call it "one of the worst things [intel] has ever done" i assume D:
<whitequark>
awkward
<TD-Linux>
:3
<hl>
I assume the name of the eSPI architect isn't Marsia Mariner
<whitequark>
no
<TD-Linux>
I mean, your regular readers will know it's hyperbole because Intel is really good at making things that are even worse :^)
<hellsenberg>
lmao
<TD-Linux>
oh no I'm reading it now
<TD-Linux>
>removes sideband pins
<TD-Linux>
>still has CS, Alert, and Reset sidebands for every separate device
<TD-Linux>
tunneling smbus over eSPI uses more pins than smbus
<hellsenberg>
but it's not as easy to sniff, I guess
<whitequark>
TD-Linux: ... yeah
<whitequark>
what
<whitequark>
why
<TD-Linux>
smbus is 2 pins, adding a smbus to eSPI translator is 3 pins
<hl>
in other news USB4 is supposed to have its spec released right about now. yet there's been no word. siigh.
<TD-Linux>
well I guess you'd translate SMBUS interrupt to eSPI alert so it's 3 and 3
<hl>
I mean when the USB4 spec is published I will probably read it and start screaming, so maybe it's for the best, but still, I was looking forward to its publication
<whitequark>
TD-Linux: yes i understand it
<TD-Linux>
whitequark, I thought I might have made a mistake cause I was "wut" too
<TD-Linux>
how do IO address space read/writes work? I don't see a separate message type
<sorear>
Given how much of the complexity of these protocols has to do with multimaster, I’m surprised I haven’t seen a token ring style reduced pin interface
<whitequark>
page 61
<whitequark>
sorear: DON'T GIVE THEM IDEAS
<TD-Linux>
I'm confused about the transaction layer's cycle types vs the commands
<TD-Linux>
sorear, mostly unrelated but a lot of lithium battery management chips use that as a way to avoid needing isolators
<TD-Linux>
they just have to talk to the chip 4.2v up or down
<whitequark>
ok, so here's my idea for the new Glasgow IO architecture
<whitequark>
let's take OGPIO as an example.
<whitequark>
it would have the following ports:
<whitequark>
- data
<whitequark>
- en (if high, causes data to appear on pins)
<whitequark>
- o_tag
<whitequark>
- i_tag
<whitequark>
now, what are the tags? they're basically a buffer-aware ack mechanism
<whitequark>
for example, suppose i have 4 registers inside the OGPIO for some reason. if i was using stb/ack signaling, it would mean that i can get a new value out there every 4 cycles.
<whitequark>
but with en/tag signaling, what i can do is:
<whitequark>
1. present data, raise en; 2. each time i_tag changes, present new data; 3. once i'm out of data, lower en; 4. wait until i_tag == o_tag.
<whitequark>
*pipeline-aware ack mechanism
<whitequark>
i mean, maybe tags aren't the best idea for this. i'm not sure yet. maybe it should be something more like en/stb/empty
<whitequark>
right, a pipeline is essentially a high latency FIFO, so one could imagine en/empty/full working
* tnt
is lost
* hellsenberg
is lost as well
<thaytan>
whitequark, wishbone does something like that doesn't it?
<thaytan>
it's been years since I looked at it
<whitequark>
tnt: huh. that incomprehensible?
<whitequark>
shit. let me try again
<whitequark>
so what i'm trying to support is two primary use cases
<electronic_eel>
whitequark: this OGPIO, will it always be just one bit / pin wide or can you also configure it to be a parallel bus of for example 8 bit width?
<whitequark>
electronic_eel: i don't see what difference the width makes so it should be configurable
<whitequark>
the semantics is exactly the same
<electronic_eel>
ok. what about sending data to a foreign clock, like glasgow being spi slave?
<whitequark>
that's more complicated
<electronic_eel>
i know, that's why I'm asking ;)
<whitequark>
i admit i haven't given it much thought yet
<whitequark>
electronic_eel: the case i'm thinking about is things like SPI over BSCAN
<whitequark>
well, one primary caes
<whitequark>
the second primary case is the IOB FF latency
<whitequark>
and sometimes CDC latency as well
<electronic_eel>
sorry, I don't understand what IOB latency has to do with a concept like this
<electronic_eel>
you need a mechanism to control the timing of en or ack signals in respect to the data, that is obvious
<electronic_eel>
oh, another point that came to my mind: there are a bunch of protocols that use one wire for input and output and swtich directions based on commands, like SWD, eSPI,...
<whitequark>
or just good old QSPI
<whitequark>
yes. of course.
<electronic_eel>
at least for cases where glasgow sends the command to switch, it would make sense to plan for that in the concept
<whitequark>
oh, that's easy, oe is controlled with another OSERDES
<whitequark>
ok so IOB latency.
<whitequark>
or CDC.
<whitequark>
let's say i have a JTAG applet and each input has a 2FF on it
<whitequark>
this means that input data is delayed 2 cycles compared to my output data. i have to deal with that.
<electronic_eel>
ok, but does the gateware need to do that or can it by done by the python program later on when it decodes the data?
<whitequark>
of course gateware needs to do that
<whitequark>
why would you possibly want this in python?!
<whitequark>
i mean, that's not all
<whitequark>
right now, you can drive JTAG at say 8 MHz but above you stumle into the problem that it's not pipelined (as in, doesn't treat the 2FFs as pipeline) and so it breaks
<whitequark>
what i want is to drive JTAG at up to sysclk, with no additional logic like a PLL.
<whitequark>
this means using DDR to drive the clock.
<whitequark>
this also means i may need to use DDR to capture on a specific edge as well (i think not with JTAG but with other protocols certainly)
<whitequark>
this means there's one more cycle of latency.
<whitequark>
i want all of this to be handled transparently, such that you can mix and match various configurations
<electronic_eel>
hmm, I fear I'm just stealing your time because I don't really understand the problems you are talking about. I'm an absolute noob at HDL and this is a big bit above my league
<whitequark>
oh and re: doing things in python
<whitequark>
there are two general problems
<whitequark>
a) python absolutely sucks at bit manipulation
<whitequark>
b) python is not the only bus master
<whitequark>
for example i specifically want SPI over BSCAN to work completely in gateware
<whitequark>
yes you could generate gigabytes of test vectors. no there is no reason to it's stupid
<hellsenberg>
having to do bit manipulation with something that sucks at it sounds like hell
<whitequark>
and yes you could push the latency handing into the SPI-over-BSCAN adapter, no there is no reason to again
<whitequark>
i think gateware should just do something sane on every layer
<whitequark>
electronic_eel: anyway. that's fine. i could never design the protection board, so it's all good we have diversity of skills
<whitequark>
(i didn't even realize you could use FETs like that. although it's obvious in retrospect.)
<electronic_eel>
yes, there are a lot of different skills combined here in the channel and that makes it intersting
<electronic_eel>
I also always wanted to learn a bit HDL, thought Glasgow would be a good opportunity for that
<whitequark>
sure, why not
<whitequark>
most of HDL currently in glasgow is fairly primitive
<whitequark>
which makes it easier to learn from it, I think
<whitequark>
it's really written with a lot of KISS. which unfortunately no longer really cuts it
<hellsenberg>
maybe KIASAP would do (keep it as simple as possible)
<hellsenberg>
or not, maybe divide and conquer would do better? *shrugs*
<whitequark>
tbh i think most of those catchphrases are useless
<hellsenberg>
> Invoking the ‘single responsibility principle’, programmers have been known to brutally decompose software into a terrifyingly large number of small interlocking pieces—a craft rarely seen outside of obscenely expensive watches, or bash.
<hellsenberg>
O_o
<whitequark>
tef has a way with words.
<hellsenberg>
oh, this is written by tef?
<whitequark>
yes
<hellsenberg>
good to know, I'll check their writings
<hellsenberg>
excellent read. thanks for sharing!
pie_ has joined #glasgow
pie_ has quit [Ping timeout: 250 seconds]
ali_as has joined #glasgow
pie_ has joined #glasgow
carl0s has quit [Remote host closed the connection]