cr1901_modern has quit [Ping timeout: 276 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
craigjb has joined ##openfpga
craigjb has quit [Ping timeout: 268 seconds]
mumptai has joined ##openfpga
emeb_mac has quit [Ping timeout: 240 seconds]
s_frit has quit []
rohitksingh has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
edmund_ has quit [Quit: Ex-Chat]
Thorn has joined ##openfpga
Bike has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
<ZirconiumX>
tnt: When you really *have* to do CDC, what resources do you recommend for it?
<tnt>
What do you mean ?
<ZirconiumX>
So, I need to produce a video output of some form, which means producing signals at fairly specific frequencies that can't be approximated by a clock enable
<tnt>
Oh. I read CDC as the USB ACM/CDC thing :p
<ZirconiumX>
Possibly also a question for ZipCPU
<tnt>
Well I would generate the required clock with a PLL and use Async FIFOs to pass data if needed.
<ZirconiumX>
Mmm. That makes sense
<tnt>
Now, FIFOs is the most "generic" answer but sometime other solutions are more appropriate and depends on the specific case ...
<tnt>
Like for instance sometime it's more beneficial to use ping/pong buffers and a 'toggle' line that cross the clock boundary.
<ZirconiumX>
As a side note, I'm a little unsure it's possible for the Cyclone V PLLs to produce a signal precise enough
<tnt>
Then you need to feed the clock externally.
<tnt>
There is no magic, if you need something top operate at frequency 'f' ... you either need that clock directly, or something close enough that you can generate it with a PLL/DCM from the FPGA you're using.
<ZirconiumX>
Which doesn't seem feasible for the MiSTer at least
<tnt>
What's the clock for ?
<ZirconiumX>
NTSC signal carriers
<ZirconiumX>
The alternative is trying to do some magic in hardware where the NTSC frame gets converted into VGA or whatever
<tnt>
In general you can input clock on any pin as long as you don't need any precise phase relationship between that clock on that pin and the internal logic.
<ZirconiumX>
I'll probably need to look at what the MiSTer cores can do
<tnt>
To output NTSC ? or to capture it ?
<ZirconiumX>
The hardware they emulate works at a given resolution and frequency which it seems they output natively
<ZirconiumX>
However I don't know how well a monitor would handle me shoving NTSC down a VGA connector :P
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
ZipCPU|AFK is now known as ZipCPU
emeb has joined ##openfpga
gnufan_home has joined ##openfpga
gnufan_home has quit [Ping timeout: 276 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
gnufan_home has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
freemint has joined ##openfpga
<ZirconiumX>
ZipCPU: You might want to read the chat history
craigjb has joined ##openfpga
AndrevS has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
emeb_mac has joined ##openfpga
emeb_mac has quit [Client Quit]
<ZipCPU>
ZirconiumX: Do you still have a question?
<ZirconiumX>
My question's still valid, yeah
<ZipCPU>
So ... let me see if I understand ... you want to go from one clock domain to another, and want to know if you need a CDC?
<ZipCPU>
Or is the question more about how to generate the clock you need?
<ZirconiumX>
I don't think I can generate it with a PLL, so it'll need to be another clock domain
<whitequark>
even if you generate a clock with a PLL, you get two clock domains
<ZipCPU>
Ah, no, that's not what CDCs are
<ZipCPU>
Yes, exactly what whitequark just said
<ZirconiumX>
Mmm
<whitequark>
(in the general case; in some rare circumstances you *could* use a PLL to generate a derived clock phase-aligned with your original clock, but it's very, very rare)
<ZipCPU>
if you have one piece of code @posedge CK1 and another piece of code with @posedge CK2, then you have two clock domains
<ZirconiumX>
Okay
<ZipCPU>
If logic set @posedge CK1 needs to be read/referenced by logic clocking at @posedge CK2, then you need to *cross* clock domains
<ZirconiumX>
I think what I really need to do is work out what I need to output, and then work backwards to figure out how to get there
<ZipCPU>
Where this comes into play the most for me is if/when my memory is running at one speed and my user logic (i.e. video display output) is running at another
<ZirconiumX>
Indeed, video is the main aim here
<ZipCPU>
What output clock frequency do you need? Do you know yet?
<ZipCPU>
I also have demo video code, if that's what you need .... ;)
<ZirconiumX>
I need NTSC and PAL composite support, or else some way of emulating those signals in VESA
<ZirconiumX>
And I am well aware of how cursed the idea of NTSC in VESA is
<ZirconiumX>
Put it this way: the circuitry I'm trying to emulate is old enough to be referred to as a Programmable CRT Controller
<ZipCPU>
Will you be using any SDRAM?
<ZipCPU>
External RAM at all?
<ZirconiumX>
I haven't decided yet. I can fit my framebuffer within BRAM, I think, but it needs a fairly wide bus
<ZirconiumX>
I'm aiming for accuracy, but I don't feel like trying to emulate quirks like read-modify-write memory stalls unless I have to
<ZipCPU>
Do you have a video simulator yet, so you can see the output from your core on your screen when running in a simulator?
AndrevS has quit [Remote host closed the connection]
<ZirconiumX>
I'm using nMigen, so I can fire up an SDL framebuffer
<ZirconiumX>
Through Python
<ZipCPU>
What hardware?
<ZirconiumX>
The GPU for the PlayStation 2; the Graphics Synthesizer
<ZirconiumX>
I can send you a copy of the manual for reference, if you want
<ZipCPU>
Which FPGA?
<ZirconiumX>
Plus or minus the key undocumented bits
<ZirconiumX>
Cyclone V; my development board is one of the smallish SoCs
<ZipCPU>
Do you need synchronized audio as well>
<ZipCPU>
?
<ZirconiumX>
Audio is a non-goal at the moment
<ZipCPU>
That makes things easier
<ZirconiumX>
Because I'd need to emulate an entire subsystem for that
<ZipCPU>
How accurate do you want to be on the NTSC timing? Is close enough good enough for you?
<ZirconiumX>
I have no idea what the tolerances are on the only CRT I have in the household
<ZirconiumX>
And for some reason I don't feel like finding out the hard way
<ZipCPU>
Meh ... it's not that hard ;)
<ZirconiumX>
What makes it a little difficult is that my dev board has HDMI and VGA out only
<ZirconiumX>
So composite might require hacking an adapter
<ZipCPU>
Yes. But ... that much is beyond anything I've done
<ZipCPU>
So ... is your question how to generate the clock in the first place?
<ZipCPU>
pixel clock that is?
<ZirconiumX>
Timings in general, mostly
Asu has quit [Quit: Konversation terminated!]
<ZirconiumX>
The "programmable" part means I need to handle whatever the hell I get thrown
<ZipCPU>
You mean, how do you generate a clock at an arbitrary rate, where you don't know the rate before hand when you build your FPGA image?
<ZirconiumX>
The manual suggests that the hardware uses a 135MHz PLL for VESA, a 54MHz PLL for NTSC and a 53.9MHz PLL for PAL
<ZipCPU>
So ... you need to be able to switch between these frequencies in real time on your board, as you switch configurations?
<ZirconiumX>
How do I write logic that can withstand sending data to something else that runs at arbitrary clock speeds
<ZirconiumX>
And yes, I do :|
<ZipCPU>
That's a basic clock domain crossing, separate from clock generation
<ZipCPU>
I have example code that does that for video that you are welcome to look at
<ZipCPU>
I also wrote an article recently about how to generate a clock signal at an arbitrary rate
<ZipCPU>
53.9-135MHz might be a bit of a stretch, though, for the clock generator ... maybe not, you'd need to try it.
<ZipCPU>
Another option would be to dynamically adjust/reprogram the PLLs on your board
<whitequark>
if you need a FIFO, nMigen has an async FIFO in its standard library
<ZirconiumX>
Yup, I've tried to familiarise myself with the nMigen standard library
<whitequark>
it's true that you still need to understand how to use it, but it's using Cliff Cummings' excellent design
<whitequark>
note that dynamic PLL reconfiguration can be quite challenging
<ZipCPU>
whitequark: How so?
<ZipCPU>
(Don't get me wrong, I'm not necessarily disagreeing, but I'd love to hear any reasons you might have for why this would be so challenging ...)
<whitequark>
ZipCPU: in my experience it's not very well documented by vendors
<ZipCPU>
That's fair
<whitequark>
there's nothing inherently hard about it (unless you hit silicon bugs...) but it's a rare use case
<ZipCPU>
I would argue that there is at least one thing inherently hard about it: debugging the design without an actual (separate) hardware oscilloscope
<ZipCPU>
(I keep my hardware scope in a box most days, and only rarely drag it out. It has yet to earn itself a permanent position on my desktop.)
<whitequark>
I certainly tend to assume that anything involving FPGAs would also involve a scope. Especially if there are multiple clocks. But I might be biased.
* ZirconiumX
is too poor for a scope >.>
<ZipCPU>
ZirconiumX: That was my position when I got started (on my own), and so I seem to have the opposite bias of whitequark
<ZipCPU>
I tend to do all my logic debugging with my own internal logic analyzer. One of the problems with this approach is that it's very dependent upon the existence of a working clock
<whitequark>
ZipCPU: after I moved out, I think I spent some of my first discretionary income on a scope. That scope's still with me today.
<whitequark>
certainly has saved me a lot of times... but my FPGA designs often involve things like reverse-engineering some interface.
<whitequark>
or in case of Lattice, the ECP5 SERDES.
<whitequark>
so a scope is not really optional for me.
<ZipCPU>
Yeah, that makes perfect sense ... now that you explain it
<whitequark>
ZipCPU: as for an internal logic analyzer, there is one for Migen, and I built a few custom ones for some of my designs.
<ZipCPU>
me, when I started my "business" doing FPGA work ... my first purchase was for a $150 dev board, and I was really scraping to get that far
<whitequark>
if the FPGA is fabric-limited, it is often a problem that adding this logic analyzer pushes it out of timing closure
<ZipCPU>
Yes!
<ZipCPU>
However, I struggle to keep all my fingers on all of those scope probes
<whitequark>
hah. yes.
<whitequark>
I have certainly exposed internal FPGA signals on GPIO headers before, to be used with an external logic analyzer.
<ZipCPU>
The other big scope problem I struggle with is that many of the things I need to debug have *lots* of signals, and maintaining context between all of them can be a challenge as well.
<whitequark>
it works fine at low frequencies, but skew starts to be a real problem if you go higher.
<ZipCPU>
My scope doesn't go that high
<ZipCPU>
(I bought a cheap one)
<whitequark>
I use a 4ch Rigol with 200 MHz of bandwidth, in theory
<whitequark>
in practice the fastest signal you can meaningfully observe is around 100 MHz, higher if it's periodic like a clock
<ZipCPU>
I only bought 100MHz, from picoscope ... it's a nice scope, but I'll probably be cursing myself for not purchasing more bandwidth
<whitequark>
then there's PCI Express at 2.5 Gbps
<ZipCPU>
Yeah ... not sure how I'd debug that
<whitequark>
sampling scope.
<whitequark>
a used sampling scope that goes to many GHz costs as much as a new Rigol on eBay.
<whitequark>
of course, this doesn't work if you want to capture complete communication traces, as opposed to e.g. looking at the eye diagram
<whitequark>
but fortunately, you have a perfectly good FPGA sitting right there that can capture complete traces--and since PCIe is not latency sensitive, you can just add a FIFO.
<whitequark>
so it doesn't punish you nearly as much timing wise
<ZipCPU>
I have a project I'm currently working on where I want to log and store many, many MB of an 800Mb/s stream. Thankfully, the stream only comes in one bit at a time, so I should have a chance.
rohitksingh has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
<gruetzkopf>
hm, the highlight on PCI is always fun