<pointfree>
Marex: Not sure if anyone outside the Forth community cares and I've mentioned it a few times, but I did a talk on Forth as an HDL for interactive hardware design/partial dynamic live reconfiguration on the PSoC 5LP:
<pointfree>
Although, I do see the opposing diagonals that correspond to mirroring of the interfaces to the PLD's.
<pointfree>
For the larger 128x96 switching matrix that goes to the port interfaces I have not yet found the simple pattern to describe with a single formula.
<Marex>
so I am covering PSoC, SmartFusion (microsemi), Altera SoCFPGA and Xilinx Zynq
openfpga-bb has quit [Ping timeout: 248 seconds]
openfpga-bb has joined ##openfpga
azonenberg has quit [Ping timeout: 256 seconds]
openfpga-bb has quit [Ping timeout: 240 seconds]
openfpga-bb has joined ##openfpga
azonenberg has joined ##openfpga
azonenberg has quit [Ping timeout: 256 seconds]
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
kuldeep_ has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
fpgacraft1 has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
digshadow has joined ##openfpga
<pointfree>
Marex, will the talk be recorded?
<Marex>
pointfree: dunno, probably, will check
<pointfree>
Thanks!
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
azonenberg has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg>
aaand back after more wrangling with high packet loss
<azonenberg>
i may have to poke comcast again if this happens more
<azonenberg>
was at 79% loss for a bit
<fpgacraft1>
<laincat> yikes
<azonenberg>
Yeeeah
<cyrozap>
Marex: If I can offer a suggestion on what to say regarding the PSoC, I'd say just stick to some facts about the platform (ARM+CPLD, some have USB, etc.) and a more general description of the status of our work on it (UDBs are publicly documented, routing is not, and we're currently working to RE the latter).
<cyrozap>
Marex: i.e., anything more than one or two slides would be too much. My reasoning is that we want to avoid distributing misinformation, whether about the platform itself or how much we know about it. If people think we're too far along, they'll be disappointed to find that there isn't much code for them to play around with. If information about some RE'd parts of the PSoC turns out to be incorrect
<cyrozap>
later, we'll have to correct people if they see the incorrect slides/video.
azonenberg has quit [Ping timeout: 256 seconds]
forrestv has quit [Excess Flood]
openfpga-bb has quit [Ping timeout: 252 seconds]
forrestv has joined ##openfpga
openfpga-bb has joined ##openfpga
lain has quit [Read error: Connection reset by peer]
lain has joined ##openfpga
azonenberg has joined ##openfpga
kuldeep_ has quit [Ping timeout: 258 seconds]
kuldeep has joined ##openfpga
massi has joined ##openfpga
massi_ has joined ##openfpga
Bike has quit [Quit: sleep]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
lain has quit [Read error: Connection reset by peer]
lain has joined ##openfpga
<cr1901_modern>
azonenberg: In your CPU core (out of curiosity), when a non-trap instruction is received, which pipeline stage do you use to determine the return program counter?
lain has quit [Ping timeout: 240 seconds]
lain has joined ##openfpga
azonenberg has quit [Ping timeout: 256 seconds]
<Marex>
cyrozap: indeed
openfpga-bb has quit [Ping timeout: 258 seconds]
openfpga-bb has joined ##openfpga
azonenberg has joined ##openfpga
openfpga-bb has quit [Ping timeout: 240 seconds]
openfpga-bb has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 245 seconds]
massi_ has quit [Quit: Leaving]
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
<azonenberg>
cr1901_modern: probably exec1 in saratoga
<azonenberg>
i dont have any trap/interrupt instructions, the only things that can cause a jump are branch/call insns
m_t has joined ##openfpga
Bike has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has quit [Quit: Leaving.]
azonenberg_work1 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
azonenberg_work1 has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
carl0s has joined ##openfpga
massi has quit [Remote host closed the connection]
m_w has joined ##openfpga
carl0s has quit [Ping timeout: 256 seconds]
forrestv has quit [Ping timeout: 252 seconds]
azonenberg has quit [Ping timeout: 256 seconds]
openfpga-bb has quit [Ping timeout: 260 seconds]
carl0s has joined ##openfpga
openfpga-bb has joined ##openfpga
azonenberg has joined ##openfpga
m_t has quit [Remote host closed the connection]
m_t has joined ##openfpga
m_t has quit [Remote host closed the connection]
carl0s has quit [Quit: Leaving]
<cr1901_modern>
azonenberg: I worded my question very poorly.
<cr1901_modern>
azonenberg: In your CPU core (out of curiosity), when a non-trap *interrupt* is received, which pipeline stage do you use to determine the return program counter?
<cr1901_modern>
Non-trap interrupt being "an event where the current instruction need not be restarted"
m_t has joined ##openfpga
plaes has quit [Remote host closed the connection]
plaes has joined ##openfpga
plaes has joined ##openfpga
<azonenberg_work>
cr1901_modern: I don't have any
<azonenberg_work>
the CPU executes sequentially (within each virtual thread) except when doing a jump or conditional branch
<azonenberg_work>
there are no traps or interrupts whatsoever
plaes has quit [Quit: leaving]
plaes has joined ##openfpga
plaes has joined ##openfpga
<cr1901_modern>
erm...
<cr1901_modern>
that's all I have to say: erm... :P
<azonenberg_work>
what do you need them for? All the hard realtime stuff is done in FPGA fabric
<azonenberg_work>
you need interrupts about as much as you do in a typical linux app, which is to say not at all
<azonenberg_work>
the CPU is entirely event driven programming
<azonenberg_work>
you get a queue of events from various hardware devices
<azonenberg_work>
and you act on them as time permits
<azonenberg_work>
in a classic CPU you have very tight hard realtime constraints where the CPU has to set up DMA buffers etc within a few clocks of some event happening to avoid data loss
<azonenberg_work>
in antikernel, the hardware does the malloc and DMA without software involvement
<azonenberg_work>
so the tight hard realtime constraint is no longer there
<azonenberg_work>
now you have a looser constraint that the CPU has to consume buffers at least as fast as they're being generated or you run out of ram
<azonenberg_work>
(or hit a quota limit, if you implement that)
<azonenberg_work>
But it's OK if you take some time to do something else, let a few packets build up, then process them later
<cr1901_modern>
azonenberg_work: Polling for external events personally skeeves me. I would rather be notified of them
<azonenberg_work>
cr1901_modern: you don't poll
pie_ has joined ##openfpga
<azonenberg_work>
You read an event queue
<azonenberg_work>
If there'
<azonenberg_work>
If there's no events, you can either go back to processing CPU-y stuff
<azonenberg_work>
Or you can block
<cr1901_modern>
it's still the burden of the user to check
<azonenberg_work>
the common flow in my case is to block until an event comesi n
<azonenberg_work>
then act on that event, then go back to idle and block
<azonenberg_work>
Like a socket server
<azonenberg_work>
i don't usually have stuff going on in between read()s
<lain>
cr1901_modern: you probably wouldn't like any modern high-performance ethernet implementation then ;)
<azonenberg_work>
Think about how Windows does this at the low level (below all of the .net etc)
<lain>
which in this case just means it isn't scheduled for execution until a message is queued
<azonenberg_work>
and DispatchMessage in antikernel would be a big switch statement you wrote
<azonenberg_work>
Yep
<azonenberg_work>
exactly
<cr1901_modern>
Do keyboard interrupts not exist anymore?
<lain>
well, usb doesn't really have the concept of interrupts per se
<azonenberg_work>
cr1901_modern: in any modern desktop OS you dont get interrupts in userspace apps
<azonenberg_work>
interrupts may go to the kernel driver
<lain>
^ this
<cr1901_modern>
azonenberg_work: That's not my point. You completely did away w/ interrupts
<lain>
ultimately it all boils down to events reaching apps
<azonenberg_work>
cr1901_modern: Because i dont need them
<whitequark>
interrupts are a pretty awful concept to be honest
<azonenberg_work>
all of the FIFO and buffer manipulation etc is done in the silicon peripheral driver
<whitequark>
it involves a lot of assumptions on the structure of generated code by the hardware
<azonenberg_work>
your app just sees a stream of events
<whitequark>
cortex-m knows the C ABI
<lain>
cr1901_modern: antikernel has the "kernel" as a series of hardware components. what azonenberg_work is saying is: in a normal computer today, interrupts hit the kernel, but the "kernel" in antikernel is fpga junk that present events to the application layer
<azonenberg_work>
imagine reading a /dev file
<azonenberg_work>
for say a uart
<whitequark>
on top of that frankly I think they are actually too hard to use correctly and something like automatic inserting of calls on loop back-edges is a better idea
<azonenberg_work>
you dont get interrupted when a keystroke arrievs
<whitequark>
as it already happens in e.g. java
<azonenberg_work>
you just do a blocking or non-blocking read on the file handle
<azonenberg_work>
and decide what to do if data is/isnt available
<whitequark>
this is a superset of what e.g. epoll()+signalfd() do
<cr1901_modern>
lain: Okay, I see
<azonenberg_work>
cr1901_modern: for example, with a software tcp/ip stack and a hardware ethernet MAC on antikernel
<azonenberg_work>
your app sees a stream of ETH_NEWFRAME events
<azonenberg_work>
each containing a (RAM address, message length) tuple
<cr1901_modern>
Then your app is just a normal event-loop type of deal
<azonenberg_work>
you map that page of ram and see a short pseudo-header with the source/dest MAC address followed by frame payload
<azonenberg_work>
Which you can crunch as you see fit
<azonenberg_work>
Exactly
<azonenberg_work>
a timer etc is the same deal
<azonenberg_work>
you just get an event at regular intervals
<azonenberg_work>
which you can process whenever it's convenient
<azonenberg_work>
just like a WM_TIMER message in native windows programming
<azonenberg_work>
even if you're using .net or wpf or mfc or gtk or qt or whatever, you still have most of this stuff going on under the hood
<cr1901_modern>
What about task swapping... is it a hybrid between coop/preemptive? The preemptive part being the event itself/coop being to yield in response?
<azonenberg_work>
The current scheduler is a pre-emptive barrel scheduler
<azonenberg_work>
every clock cycle a new thread runs
<azonenberg_work>
When you issue a blocking read, you will be (i never implemented this part fully) removed from the run queue and not scheduled until a message shows up
<cr1901_modern>
That can't be good for cache unless you're using ASID
<azonenberg_work>
I have separate cache banks per thread
<azonenberg_work>
to avoid thrashing
<azonenberg_work>
The next-gen CPU I started to spec out (but havent implemented) will be full hyperthreading
<azonenberg_work>
So you can run one thread at full utilization if nobody else is using the CPU
<azonenberg_work>
vs being limited to a max of one insn every 8 clocks like SARATOGA
<azonenberg_work>
So with that you'll have a hardware-enforced pre-emptive task switch every N clocks, N being an adjustable parameter
<azonenberg_work>
with the option of yielding earlier if you have nothing to do
<azonenberg_work>
When yielding you'll be able to either say "I'm done right now but get back to me soon"
<azonenberg_work>
or "I'm blocking on an event so take me off the run queue until a message for me shows up"
m_t has quit [Quit: Leaving]
digshadow has joined ##openfpga
<cr1901_modern>
azonenberg_work: Yea, I understand that user apps (typically) don't need interrupts, but I'm not sure I can convince myself for microcontroller applications that don't need a full blown kernel that removing interrupts is the way to go :P
<azonenberg_work>
bear in mind, antikernel is an OS