<sb0>
yes, and then it should proceed to serial boot
<mithro>
s/not/now/
<mithro>
Well, it only took me 4 hours but I'm finally at the stage where I can start work
<sb0>
mithro, what are you up to?
<mithro>
sb0: Getting the FX2 on the Opsis to load it's firmware from a "virtual eeprom" on the Spartan 6
<sb0>
no USB controller on FPGA? :)
<mithro>
sb0: ?
<sb0>
implement the USB stack on the FPGA instead of using an ASIC. there are discrete UTMI chips that can take care of the physical layer. though people using those with FPGAs typically are in the higher-margin market of USB analyzers, as projects like raspberry pi steal the oxygen of such projects, as I pointed out a few times...
<mithro>
sb0: We have a second USB port which is configured in that way
<mithro>
but nobody has had the time to get the USB stack up and running yet
<mithro>
sb0: I think last time I asked, nobody had integrated something like that into misoc yet?
<sb0>
not into misoc. for the old milkymist, I developed a limited 12Mbps USB host stack, including the physical layer (which regular FPGA IOs can handle at that speed), and that was a lot of hassle...
<sb0>
ah, yes, softusb, I see you put it into your repository
<mithro>
sb0: If I only had more time or money to get that stuff working :P
<sb0>
one particular annoyance with USB is you constantly need to poll the device, which requires a significant implementation of the protocol, and would use a lot of CPU power if you're thinking about a pure soft implementation
<sb0>
(or if you are implementing the device: answer the polls)
<sb0>
softusb is actually pretty easy to get to work, but it will only talk to HID devices
<sb0>
you can just load it into a FPGA and for a quick hack - hook up the USB device directly to FPGA IO pins
<sb0>
(there is a risk of frying the FPGA if you short pins to 5V VBUS, and the signal's electrical properties won't be to USB specs, but IME devices don't mind that last problem)
<sb0>
adding series resistors makes the signals more USB-like
<sb0>
softusb can also talk USB-midi
<mithro>
sb0: we have had that port working with a commercial USB core, so it should be pretty simple
<sb0>
oh and another annoyance with USB is if you mess up, in many cases the device will simply stop responding, without any sort of diagnostic sent back
<mithro>
sb0: yeah :(
<sb0>
and don't get a totalphase analyzer. their software craps out when you are not talking USB correctly, in other words they're useless, since if your USB stack works you are better off with wireshark
<sb0>
probably you'll want to dump the ULPI traffic to SDRAM and write your own analyzer (or recycle some open source stuff)
<mithro>
sb0: Hopefully with people getting there Opsis boards I might be able to capture one or more two developers who want to play with things like this
<mithro>
sb0: I'd really like to get the Daisho core working so we can do USB3.0
<sb0>
ah interesting...
<mithro>
sb0: first step would be using the same TI part they use, the second step would be using the high speed transceivers inside the FPGA without needing any external parts
<mithro>
(except a UTMI part for USB2.0 compat)
<sb0>
hm...
<sb0>
maybe you can hack the transceivers all the way from 1.5Mbps to USB3 rates
<sb0>
for 1.5 and 12, disable CDR, oversample, and do soft-CDR in the fabric with the DPLL (like softusb does)
<mithro>
The USB3.0 rates are done on different pins to the USB2.0 pins
<mithro>
USB3.0 adds 4 new pins to the connector
<sb0>
ah, right
<sb0>
but the transceiver hack may still apply to 480M USB... not sure if they'd do CDR properly on that sort of signal
<sb0>
probably not, in fact
<mithro>
so you effectively just have USB2.0, which then turns on the extra pins
<sb0>
though those transceivers are so fast, you can probably oversample like crazy and use a DPLL in the fabric as before
<mithro>
sb0: I wouldn't want to spend the transceivers on USB2.0 signals, you don't get many as the price point I can afford :P
<sb0>
do you have displayport working yet?
<sb0>
wondering what is the extent of migen designs using transceivers ...
<sb0>
right now there's litesata
<mithro>
sb0: We have DisplayPort output at 4k30 working
<mithro>
sb0: This might be a stupid question, but how do you generally test that a pin value "isn't read / sampled" when another condition holds?
<sb0>
what do you mean?
<mithro>
sb0: so, when you have a data line were the value is only "valid" when another pin is held low, you want to verify that the invalid data doesn't end up propagating into the system...
<sb0>
that's not supported, but wouldn't a good functional test catch this sort of problem anyway?
<mithro>
sb0: yes, probably I guess
<mithro>
sb0: how do I work with just basic signals rather then busses?
<sb0>
there is no distinction between basic signals and busses
<sb0>
a "basic signal" is a signal of length 1
<mithro>
sb0: so still use "yield from dut.sig1.write(1)" ?
<sb0>
yes
<sb0>
oh wait
<sb0>
that's what you mean by 'bus' :)
<sb0>
sorry I read too fast
<sb0>
look at the source code of what that bus write method does :)
<sb0>
yield signal.eq(1)
<cr1901_modern>
sb0: What's the limit on speed of "regular" FPGA IOs in your experience? Presumably to implement 480Mbps, you'd need special differential pair I/Os on an FPGA?
<sb0>
the problem is clock recovery. if you have a clock you can do over 1Gbps on any single regular IO.
<mithro>
sb0: is there a way to get gtkwave to show names on the states? :P
<sb0>
the typical mechanism for 12Mbps USB does 4x asynchronous oversampling and digital clock recovery
<cr1901_modern>
mithro: Manually save your gtkwave session.
<sb0>
if you want to do the exact same thing at 480Mbps you need to sample at 1920Mbps
<cr1901_modern>
So basically, a PLL in software?
<sb0>
transceivers contain analog circuitry that do the clock recovery, so they don't need to sample at crazy speed
<cr1901_modern>
well "software", but you know what I mean
<sb0>
yes, they even call it "DPLL"
<sb0>
mithro, as I'm experiencing right now for the artiq analyzer, strings in VCD suck
<sb0>
you need to define a binary signal of the right length (exactly 8 times your string length) and then assign ascii-encoded bits to it
<sb0>
and enable ascii decoding in gtkwave
<cr1901_modern>
well, I could've used that knowledge months ago...
<sb0>
mithro, besides this practical detail, there isn't infrastructure in migen to support this sort of thing
<sb0>
it wouldn't be particularly difficult to add, though
<sb0>
actually it's semi-trivial, you can just add a dummy signal in the FSM module + a case in a comb statement that assigns ASCII-encoded values to that signal
<sb0>
the only thing I'm worried about is it might make synthesizers crap out
<sb0>
well, you could add that assignment to the existing state decoder case statement. then there is little risk of synthesizers doing something stupid.
<mithro>
sb0: why would you use NextValue(self.current_bit, self.current_bit+1), NextState(x) rather then self.current_bit.eq(self.current_bit+1), NextState(x) ?
<sb0>
mithro, you should send a patch for this
<sb0>
mithro, the case decoding is combinatorial. x.eq(x+1) in a fsm.act() will create an unstable combinatorial loop.
<sb0>
*state decoding
<sb0>
whereas NextValue will create a register, and drive its control signals from the FSM decoder
<sb0>
_florent_, do you have any argument for SOP?
<mithro>
sb0: What is the current_bit_next_value_ce ?
<mithro>
I think I'm doing this wrong, I'm trying to increment a counter every time we leave this state
<cr1901_modern>
sb0: Lots of old chips used active low, an interfacing to old chips is a valid use-case for active low on FPGAs. Of course that's limited use, but still...
<_florent_>
sb0: about sop, I'm not sure we really need it, I'll check my designs, but if you want to remote it you can
sb0 has joined #m-labs
<sb0>
cr1901_modern, why do you like old chips that much?
<sb0>
they're large, slow, power-hungry
fengling__ has joined #m-labs
<sb0>
that being said, even modern chips use active-low signals, like this AD9914 DDS. but I would not call it an example of good design ...
fengling__ has quit [Ping timeout: 256 seconds]
<cr1901_modern>
sb0: Easier to understand, more fun to study where we have come from compared to where we are going, desire to preserve ones with no modern equivalent for emulation purposes.
<cr1901_modern>
sb0: Idk if you play old games or consoles, but the last point is a very real concern that doesn't really apply all that much to modern chips; programmers did some shitty things back then that require a very detailed emulation of chips that are no longer manufactured.
<cr1901_modern>
The ultimate way to preserve these chips of course, is to photograph their die and map out transistors. I'm not qualified to do that (nor do I have the materials). However, connecting to an FPGA and using a FPGA logic analyzer is an alternative.
<cr1901_modern>
Nowadays, CPUs aren't anywhere near as deterministic, so timing tricks aren't all that big of a concern (I hope...)
fengling__ has joined #m-labs
fengling__ has quit [Ping timeout: 256 seconds]
<GitHub83>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vEu7h