rohitksingh has quit [Ping timeout: 268 seconds]
Bob_Dole has quit [Ping timeout: 250 seconds]
oeuf has joined ##openfpga
rohitksingh has joined ##openfpga
craigjb has quit [Ping timeout: 246 seconds]
OmniMancer has joined ##openfpga
_whitelogger has joined ##openfpga
cr1901_modern1 has joined ##openfpga
Thorn has quit [Ping timeout: 268 seconds]
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
<ZipCPU> Have you seen this article?
<ZipCPU> Or how about this one?
gnufan_home has quit [Quit: Leaving.]
<ZirconiumX> These will be excellent reading, thank you
<ZipCPU> ;)
<ZipCPU> Don't forget the example video code, to include ASYNC FIFO integration, at
<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
<mithro> Anyone seen before?
freemint has joined ##openfpga