sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
cr1901 has joined #m-labs
sb0 has joined #m-labs
<sb0>
whitequark, what si5324 loop bandwidth did you select?
<whitequark>
the smallest numeric Hz value that was available
<whitequark>
I can rerun their tool and tell you exactly
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
<sb0>
those ice40 can only toggle ios at 250MHz and take 10ns to make a 16-bit addition?
<sb0>
pft
<whitequark>
it's not an especially fast FPGA, no
<sb0>
hardened I2C/SPI? wtf?
<whitequark>
that's only in the LX
<whitequark>
not supported in icestorm anyway
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
the LX series is rather small, it's closer to a CPLD in size, really
<sb0>
what can you do with such a low-performance device?
<whitequark>
sorry, LP/LM series
<sb0>
fancy microcontroller replacement?
<whitequark>
sure
<sb0>
it's good for super-simple moderate-timing-precision stuff, but there aren't many applications that require that. certainly not the LED blinking ("24 mA Current Drive RGB LED Outputs! 500 mA Current Drive IR LED Output!") touted on the datasheet :)
<sb0>
"embedded PWM IP" hmm
<whitequark>
it's designed for stuff like interfacing sensors
<sb0>
well, at least they're cheap
<cr1901>
sb0: ICE40 is fine for anything you would need, say, Beagle's PRUs
sandeepkr__ has quit [Read error: Connection reset by peer]
sandeepkr__ has joined #m-labs
fengling has joined #m-labs
sandeepkr_ has joined #m-labs
sandeepkr__ has quit [Read error: No route to host]
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 276 seconds]
sandeepkr has joined #m-labs
sandeepkr__ has quit [Ping timeout: 244 seconds]
kuldeep has quit [Ping timeout: 244 seconds]
sandeepkr_ has joined #m-labs
kuldeep has joined #m-labs
sandeepkr_ has quit [Read error: Connection reset by peer]
sandeepkr_ has joined #m-labs
sandeepkr has quit [Ping timeout: 252 seconds]
fengling has quit [Ping timeout: 240 seconds]
sb0 has quit [Ping timeout: 276 seconds]
key2 has joined #m-labs
<key2>
what is MultiReg used for ?
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #m-labs
sb0 has joined #m-labs
<sb0>
key2, can you write docs if I answer this question? :)
<key2>
hey
<key2>
alright
<sb0>
thx
<sb0>
MultiReg is for double-latching asynchronous signals, to avoid metastability
<sb0>
not really "advanced" design I'd argue, most real-world designs need that
<key2>
ok
<key2>
but practically, when you have let say 2 signal coming from 2 different cd
<key2>
you use multireg to do what ?
<key2>
I guess i'd need a tutorial example
<sb0>
so you have 3 clock domains, and you want to get signals from domains 1 and 2 into domain 3?
<key2>
not necessarely, i'd like to get a simple example where using multireg is needed
<sb0>
note that the *only* thing MultiReg gives you is no metastability. it has a lot of jitter, and if you put more than one bit through it, they may not arrive at the same time.
<key2>
in fact, i was reading the uart code
<sb0>
see figure 6.9 in the book I linked
<key2>
and i was wondering why the multireg was added on the rx pad
<larsc>
which synchronization primitives you can use also depends on the type of signal
<sb0>
if you put the metastable signal into e.g. a FSM, and it feeds two different registers in the FSM, then those two registers may load a different value, which can completely lock up your FSM until your design is reset
<larsc>
for metasability to resolve you also want the shortest path possible to the next register
<larsc>
so no logic in between
<larsc>
otherwise the metastability can propagate through your circuit
<larsc>
which is bad
<key2>
k
<key2>
and ISE does not calculate those stuff when doing placement ?
<larsc>
it can't
<larsc>
the only thing it might know is that your register passes from one clock domain to another
<larsc>
but the type of synchronization you want depends on your logical value of the register(s)
<larsc>
e.g. if your signal is a single clock cycle pulse
<larsc>
you can't just sample it in the target domain
<larsc>
if the target domain is slower you might miss the pulse completely
<larsc>
if the target domain is faster the pulse might be multiple clock cycles long now
<key2>
i see
<larsc>
generally speaking avoid multiple clock domains if you can
<larsc>
e.g. instead of having two clocks use a clock enable to simulate a slower clock
<larsc>
by not protecting against it you increase your MTBF (mean time between failure)
<larsc>
and even with the MutliReg it can still fail
<sb0>
generally the cost of adding MultiReg (2 FFs) is much smaller than the time spent debugging nasty bugs that involve metastability, intermittent failure and synthesis optimizations
<larsc>
the chance is just very very low, like something 1 in a trillion years or so
<key2>
could be used after a tristate right ?
<sb0>
so, as a general rule, simply add MultiReg everytime you sample a signal that is not synchronous to your current domain
<sb0>
yes, MultiReg is just made of regular FFs and will work on any regular FPGA internal signal
<key2>
k great
<key2>
btw, why did you move the stream to misoc ?
<key2>
for wishbone, i understand, as it is used between cores and is needed to make a soc
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<sb0>
stream is also a somewhat advanced thing, which has seen many refactorings and changes. i want to keep migen more simple and stable.
<key2>
ok
<key2>
would it be very complicated to create a misoc oriented for arm ? with AXI/AMBA buses and stuff like that ?
<sb0>
why do you care about ARM?
<sb0>
and I would not look at all into AMBA, nothing really uses it anymore
<sb0>
except LEON
<key2>
I was wondering if companies like synopsys or other could have interest in using misoc
<sb0>
hm, probably doesn't fit into their culture
<sb0>
unless they changed a lot recently
<sb0>
not enough TCL and IP encryption systems ;)
<sb0>
xilinx could be more welcoming maybe, if they don't see it as a threat to their "IP Catalog" and/or causing tech support issues
<key2>
sb0: my idea was to make a SoC where the ARM core was emulated in a PC over PCIe. so instead of having the ARM core, you would have a PCIe core that interfaces teh same way an ARM would
<key2>
and this way, let ppl develop a SoC where the arm would be emulated, but the rest would be in the FPGA
<key2>
so it would be possible to do a proof of concept of something without the ARM license.
<key2>
that way, one could first prove his design works, then raise money to go further
<sb0>
but even though xilinx have some decent engineers, i have the impression that a large part of their customer base is more or less the same kind of people who like SAP software and IBM mainframes
<key2>
lol
<key2>
did you get my idea ?
<sb0>
how about not giving any money to ARM and using another core?
<sb0>
there are open alternatives...
rohitksingh has joined #m-labs
<key2>
true
<key2>
and not true at the same time. Do you know anything open as powerful as an arm64 ?
<key2>
armv8
<key2>
that handles virtualization, EL1 EL2 EL3... trustzone...
<key2>
sadly i haven't seen any
<key2>
now if you are talking about a cortex M core, then yes, probably
<key2>
Also, your probability of having adopters with an ARM is higher than with an open source CPU..
<key2>
when you think about it in a company/business way... you break the paradigm that consist of saying if you want a SoC with ARM, first u put big money and get licenses... In this case u could be a student or a startup and make first a SoC with the arm being emulated. then raise and get ur asic or whatever
<key2>
and thats where the value is
<sb0>
no, value is educating students about thinking for themselves instead of just buying the ARM FUD
<sb0>
if they're doing ASICs which are about something like virtualization, why not implement it themselves?
<key2>
-- My intent is that if you include OPA into your project, all of the HDL -- and other design files that go into the same physical chip must also -- be released under the GPL. If this does not cover your usage, then you -- must consult me directly to receive the code under a different license.
<key2>
:)
<sb0>
that's already much better than the ARM licenses
<key2>
lol
<cr1901>
key2: Google "clock domain crossing", click first result. It's the most read article on EE times for a reason :P
<key2>
cr1901: wikipedia ?
<cr1901>
Second link... oops
<larsc>
for me the second link is fpga4fun
* cr1901
cries... Well for me the second link IS the EE times article
<larsc>
you click on ee links too much
<larsc>
;)
<cr1901_modern>
larsc: A serious answer to your playful response: I have a degree in EE, I kinda got content and atrophied in my knowledge. Slowly building it back up again.
<cr1901_modern>
But I won't deny that either :P
<cr1901_modern>
I think the biggest thing is that "no real deployable product can be made with what you learn solely from an EE curriculum." Prob true in many other disciplines.
<cr1901_modern>
sb0: Do you agree? ^
<larsc>
how about a arduino LED shield?
<larsc>
is schematic and layout design actual part of normal EE?
<key2>
when you have a endpoint sink, and you want to Testbench
<key2>
what is the easiest way to connect to in in the tb ?
<cr1901_modern>
larsc: Wasn't part of my curriculum. You learned it on your own time. One class (which I did not take b/c hindsight is 20/20) required you to learn it to complete the final project tho.
kuldeep has quit [Ping timeout: 244 seconds]
sandeepkr_ has quit [Ping timeout: 260 seconds]
sandeepkr has joined #m-labs
<key2>
in a module, how do I access the default clk ?
<key2>
the sysclk
sb0 has quit [Quit: Leaving]
<cr1901_modern>
key2: ClockSignal() or self.cd_sys.clk
<key2>
object has no attribute 'cd_sys'
<cr1901_modern>
Try sys then
<cr1901_modern>
oh wait sorry
<cr1901_modern>
self.clock_domains.cd_sys.clk*
<cr1901_modern>
or self.clock_domains.sys.clk; it's one of those two
<key2>
complains on all ;)
<cr1901_modern>
Did you define your own clock_domain AND are you synthesizing?
<key2>
ah
<key2>
i was simulating
<key2>
that might be why
<cr1901_modern>
No, it wouldn't be that. Migen will add any clock domains not defined for you if you're simulating.
<key2>
mmh
<cr1901_modern>
I would have to see the code, but I don't have the bandwidth to really check right now, sorry
<key2>
Do I have to do self.clock_domains.cd_sys = ClockDomain() myself ?
<cr1901_modern>
key2: The answer to that is "sometimes", and I don't know all the situations where you do and where you don't.
<cr1901_modern>
sb0: (When you come back) Under what circumstances do you need to do "self.clock_domains.cd_sys = ClockDomain()" SOMEWHERE in your Migen design? I.e. Under what conditions will migen not add it for you automatically.
<larsc>
if it is not the default domain
<cr1901_modern>
larsc: When does Migen decide cd_sys is not the default domain?
<larsc>
when you assign it manually
<larsc>
I think by default you are using the domain of the parent module
<cr1901_modern>
It's different between simulation, verilog generation, and synthesizing (based on a parameter passed to the verilog generation function)
<larsc>
if your module generates its own clock you can overwrite the domain and make sure you get a separate clock signal