genii has quit [Remote host closed the connection]
unixb0y has quit [Ping timeout: 245 seconds]
gsi__ has joined ##openfpga
unixb0y has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 246 seconds]
gsi_ has quit [Ping timeout: 245 seconds]
SpaceCoaster has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
dj_pi has quit [Ping timeout: 250 seconds]
dj_pi has joined ##openfpga
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
rohitksingh has joined ##openfpga
pie___ has joined ##openfpga
genii has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
Miyu has quit [Ping timeout: 246 seconds]
Bike has quit [Quit: leaving]
Bike has joined ##openfpga
Bike has quit [Client Quit]
genii has quit [Remote host closed the connection]
rohitksingh_work has joined ##openfpga
OmniMancer has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh_ has joined ##openfpga
rohitksingh_ has quit [Ping timeout: 240 seconds]
dj_pi has quit [Ping timeout: 244 seconds]
emeb_mac has quit [Ping timeout: 245 seconds]
<azonenberg>
Finally getting around to writing a tool that's long overdue
<azonenberg>
xvcd to jtaghal bridge
<azonenberg>
So you can use vivado to talk to a jtaghal-supported dongle
<azonenberg>
the question is how to do it without adding all kinds of layering violations and/or breaking stuff
<azonenberg>
Because the xvcd protocol is low level and jtaghal's network protocol is much more abstract
<azonenberg>
in particular i don't allow you to send raw TMS data
<azonenberg>
while that's all xvcd does
<azonenberg>
So what i think i might have to do is implement the tap state machine in the bridge
<azonenberg>
then send high level commands like "go to shift-DR"
<whitequark>
why not bypass directly to a lower layer?
<azonenberg>
whitequark: That's an option too
<azonenberg>
But it would have to be done very carefully
<azonenberg>
in particular, i need to not break any optimizations in the drivers or dongles that remove redundant state changes
<azonenberg>
those get confused when you don't use the state-level API
<azonenberg>
which is one of the reasons that i explicitly did not support raw TMS bitbanging in the network api
<azonenberg>
To force you to use that gateway
<whitequark>
azonenberg: ahh, so the problem is high level *backends*
<whitequark>
whereas in glasgow there is no high level backend, pipelined raw (ok, slightly cooked) commands are the way to go
<whitequark>
makes sense
<whitequark>
azonenberg: btw, my idea for jtag accelerators (like for mips ejtag) on glasgow would be to run boneless on it
<whitequark>
compile small python snippets to boneless assembly
<azonenberg>
whitequark: yeah its a high level backend
<azonenberg>
among other things it's optimized for things like polling loops over high latency transports like usb
<azonenberg>
where you push as much intelligence as possible to the far end of the cable
<azonenberg>
jtaghal was also intended to be used over WANs so same deal
<azonenberg>
you dont want your polling loop going over the VPN
<azonenberg>
just the register value when it finally is ready
<azonenberg>
I havent implemented as much offload as i eventually wanted, but that was kinda the design goal
<whitequark>
currently the mips ejtag backend in glasgow is like... 1-2 gdb steps per second
<whitequark>
however, the amount of work required to single step mips is absurd
<azonenberg>
meanwhiel with antikernel i had like 9.8 Mbps of throughput from my PC to the NoC
<azonenberg>
with 10 MHz TCK
<azonenberg>
it was super tuned :p
<whitequark>
have you seen ejtag?
<azonenberg>
I started implementing it
<azonenberg>
then switched to arm :p
<azonenberg>
i got to the point i could execute single instructions on the cpu i think
<azonenberg>
but never made a full debug stub
<azonenberg>
whitequark: anyway, the jtaghal API does have a low level mode
<azonenberg>
But i intentionally did not expose that on the network interface
<azonenberg>
one alternative strategy would be to make the bridge link directly to libjtaghal and open the cable directly, vs connecting over socket
<azonenberg>
another strategy would be to build this into jtagd
<azonenberg>
and just add an alternate mode for socket protocol
<azonenberg>
that actually seemsl ike the best choice
<azonenberg>
that way i get the full low level api and the socket code is already written
<azonenberg>
i just have to call one thread or another on an incoming connection
<azonenberg>
depending on which protocol is selected
<azonenberg>
and pass in the socket and interface handle
Asu has joined ##openfpga
<openfpga-bot>
[jtaghal-apps] azonenberg pushed 1 new commit to master: https://git.io/fh1xu
<openfpga-bot>
jtaghal-apps/master 4a6a07a Andrew D. Zonenberg: Initial work towards XVCD protocol support in jtagd. Still have to do shift command.
Miyu has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<tnt>
What would be a good architecture (simple/easy) to write an interpreter for and that's supported by GCC or llvm ? Basically I don't see myself writing a C compiler for my soft core any time soon, but maybe writing an interpreter for some other byte code that already has a compiler would be an option to allow some quick tests.
dj_pi has joined ##openfpga
<whitequark>
why do you want gcc or llvm specifically?
<tnt>
ok, fair enough, ... I actually don't.
<tnt>
you had something else in mind ?
<whitequark>
maybe forth or scheme implementation
<sxpert>
tnt: you could probably port tcc
<tnt>
whitequark: can you compile C to forth bytecode or somethng easily ?
<tnt>
sxpert: you might underestimate just how much I suck at writing compilers :p
<whitequark>
tnt: forth does not have bydecode.
<whitequark>
*bytecode
<whitequark>
the whole point is that the runtime is so thin, you can just write it in assembly
<sxpert>
tnt: possibly
<sxpert>
forth is just a giant stack and a list of orders
<whitequark>
tnt: what's the end goal? just running some c code?
<tnt>
right. But ideally I'd want to write C or rust or something like that... not Forth. I mean looking at it, I might as well program in my ASM directly rather than program in forth :p
<Flea86>
sxpert: Nothing is impossible, if you have enough time ;)
<sxpert>
yep
<sxpert>
for instance, I want to learn some verilog, so I'm starting an HP-saturn implementation
<sxpert>
am having trouble locating a proper tutorial though
<Flea86>
sxpert: Sounds pretty ambitious for a first .v project
<Flea86>
but my opinion doesn't carry much weight, so carry on ;)
rohitksingh has joined ##openfpga
<sxpert>
Flea86: I know the arch pretty well having spent all my high school and uni years programming in assembly on that thing ;)
<whitequark>
sxpert: the most important thing about verilog you need to know is that 99.9% of all verilog and 98% of all synthesizable verilog is wrong. the only reasonable way to write verilog is to heavily subset it and use linters in the most aggressive mode
<whitequark>
(wrong as in, it does *something* but not what you want)
<whitequark>
note: code examples from vendors are in that 98%. never trust examples from vendors, they are as shit as random code snippets from some forum.
dj_pi has quit [Ping timeout: 246 seconds]
<sxpert>
whitequark: good to know, would yosis qualify as a proper linter ?
<whitequark>
no! never use yosys to verify your verilog!
<sxpert>
ah, ok
<whitequark>
you must *always* simulate it first with iverilog -Wall
<sxpert>
ok
<whitequark>
only if it simulates correctly it has any chance of working on the FPGA
<whitequark>
(code that simulates correctly is still more likely than not to not actually work)
* sxpert
notes that
<sxpert>
hmm
<Flea86>
whitequark: That is quite a stark contrast to my experiences with VHDL
<sxpert>
how is that thing so broken ?
<OmniMancer>
Is VHDL any better about not being mostly wrong?
<whitequark>
VHDL is much better, although I still think it's not a very good language
<whitequark>
unfortunately this is irrelevant
<whitequark>
none of the open tools support VHDL
<whitequark>
sxpert: same reason C is unusable
<Flea86>
Yeah :(
<whitequark>
no thought was put into verilog's design. it's like the minimal working thing that someone signed off and said "fuck it, ship it"
<sxpert>
well, C mostly does what you want, but may explode in unpredictable ways if you don't feed the program exactly what it was designed for
<OmniMancer>
Are any of the HDLs which produce Verilog as output any better?
<sxpert>
Flea86: according to the manual it appears to not do a bunch of things
<OmniMancer>
Flea86: interesting
<Flea86>
sxpert: Yeah, cannot do packages for example
<q3k>
yeah, it's very basic
Flea86 has quit [Quit: sleeptime!]
OmniMancer has quit [Quit: Leaving.]
genii has joined ##openfpga
<sxpert>
whitequark: ok, getting a hang of it. thanks
C_Elegans-work has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
Bob_Dole has quit [Remote host closed the connection]
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 250 seconds]
emeb has joined ##openfpga
Bob_Dole has joined ##openfpga
the_new_lfsr has joined ##openfpga
<the_new_lfsr>
seeing the level of topics discussed on this chat I feel a little bit embarassed to ask for help with my problem... I am having trouble trying to compile the simple blink example from chapter 2 of the zipcpu tutorial: g++ is telling me this /tmp/ccIGBNKe.o: In function `main': blinky_param.cpp:(.text+0x149): undefined reference to `Vblinky_param::trace(VerilatedVcdC*, int, int)' collect2: error: ld returned 1 exit status
<ZipCPU>
the_new_lfsr: Did you remember to run Verilator with the --trace option?
<the_new_lfsr>
I revised my code but I am not able to find the problem. (Also I as expirienced in C as someone who just made some little projects with arduino so there could be a problem...
<the_new_lfsr>
yes!
<ZipCPU>
Are you including verilated_vcd_c.cpp on your compile line?
* ZipCPU
is guessing, and hoping his guess is convincing
<ZipCPU>
The other way to go about it would be to apply nm to your Vblinky_param__ALL.a file, and grep for trace ... just to make sure the function ended up in the archive in the first place
<ZipCPU>
nm is really a great tool for debugging this sort of thing
<the_new_lfsr>
nope, it gives the exact same error
<ZipCPU>
Ok, let's go for "nm"
<ZipCPU>
For example, if you ran Verilator with --trace, but forgot to run a rebuild in the obj_dir directory, you might get this error
<ZipCPU>
Likewise, if you run Verilator with -trace instead of --trace you might get this error
<ZipCPU>
nm should help you chase down where the error is coming from though
<the_new_lfsr>
so... how I run nm? the_new_lfsr is confused
<ZipCPU>
nm Vblinky_param.a
<ZipCPU>
Sorry, nm Vblinky_param__ALL.a
<the_new_lfsr>
do you want the output? is totally out of my reach to understandit
rohitksingh has quit [Ping timeout: 250 seconds]
<ZipCPU>
There's a C++ decoder for the symbols. "T" means the symbol is defined, "U" means it is undefined ... let me look up the name of the decoder ...
<ZipCPU>
Here it is: c++filt symbolname. So I just ran: c++filt _ZN7Vblinky16traceInitThis__1EP13Vblinky__SymsP12VerilatedVcdj
<ZipCPU>
That tells me that the symbol decodes to Vblinky::traceInitThis__1(Vblinky__Syms*, VerilatedVcd*, unsigned int)
<ZipCPU>
You are looking for the "missing" symbol, to see if it is defined (or not)
<ZipCPU>
For example, nm gives me the symbol _ZN7Vblinky5traceEP13VerilatedVcdCii. When I run c++filt _ZN7Vblinky5traceEP13VerilatedVcdCii, it returns Vblinky::trace(VerilatedVcdC*, int, int) -- the symbol you are looking for
<ZipCPU>
Also on the nm output is a "T" just before _ZN7Vblinky16traceInitThis__1EP13Vblinky__SymsP12VerilatedVcdj, meaning that the Vblinky__ALL.a file I applied it to contains the appropriate symbol
<the_new_lfsr>
but I have a huge amount of symbols comming out of nm, should I try them all?
<ZipCPU>
Hmm, yeah, I have 73 ... that sounds painful. Here's an alternate method you can try ...
<ZipCPU>
Do you have a file name Vblinky_param__Trace.cpp?
<ZipCPU>
in your obj_dir directory?
<the_new_lfsr>
yes
<ZipCPU>
Also, what command line are you using for Verilator?
<ZipCPU>
I'll take my successes wherever I can get them. You are invited to join in the celebrations ;)
soylentyellow_ has quit [Ping timeout: 268 seconds]
<the_new_lfsr>
your tutorial is great, but I feel I need to learn tons of things like what make command really does, C++... do you think I should start from somewhere else? I would like to have some solid ground at programming FPGAs and I am a bit lost right now
<ZipCPU>
Do you have a C++ background at all?
<the_new_lfsr>
I am going to say no
<ZipCPU>
Ok, how about any C in your background?
<the_new_lfsr>
when I was doing research with FPGAs I was using VHDL and no simulations at all hahaha
<ZipCPU>
Been there, done that ... only with Verilog
<the_new_lfsr>
yes, I know a little bit from tinkering with arduinos
<ZipCPU>
So ... I like the approach used in the tutorial because the C++ used in Verilator makes it easy to integrate your FPGA simulation with the O/S for all kinds of fun uses: TCP/IP, hardware serial ports, windows system, etc.
<ZipCPU>
But, yes, it does require a bit of C background. The C++ background beyond that is really just knowing that there exist classes (like structs) that have functions defined as part of them.
<ZipCPU>
I really don't get into the C++ I/O subsystem much
<ZipCPU>
As for "make" ... you don't need to become a make wizard, just a few tricks/tools in your bag should be sufficient
<ZipCPU>
Know how to create a basic Makefile, how you can create a target from dependencies, and how you can use variables in make and .... that should be almost all you need
<ZipCPU>
I'm not really much of a make wizard myself, although I have copied some very useful tricks from others who are
<the_new_lfsr>
yes, I get that of classes in C++. I understand the examples you have so far , though I would not know how to write them
<ZipCPU>
Once you get past the C++ function I call tick(), everything really follows the same form from one project to the next
<the_new_lfsr>
yes, I think I should learn that. Can you give me some place to learn all that?
<ZipCPU>
The examples are meant to be copied. In many ways, you shouldn't need much more
<the_new_lfsr>
thank you very much. I have to leave, I will let you return to your advanced topics hahaha
<ZipCPU>
I look forward to hearing great things from you!
the_new_lfsr has quit [Ping timeout: 256 seconds]
<tnt>
daveshah: well, that didn't take long :p "ERROR: Failed to expand region (0, 0) |_> (25, 31) of 7 SB_GBs"
<daveshah>
tnt: out of curiosity, are there constrained GBs in that design?
<tnt>
There is. Just tried to unconstrain it, but seem I get the same result.
<sxpert>
yay, 1st verilog module that works with no warnings from iverilog
<ZipCPU>
Yes, but ... does it work with no warnings from Verilator -Wall? :D
<tnt>
daveshah: but when it works, it's definitely nicely much faster ...
<sxpert>
ZipCPU: haha
<daveshah>
tnt: Can you pull and see if the GB issue is fixed?
<sxpert>
ZipCPU: it's only combinatorial logic
<ZipCPU>
*only* combinatorial logic? Fascinating. Not many designs are *only* combinatorial logic. I've done one or two, but ... they seem to be pretty rare in my experience. You must be working on something fun.
<tnt>
daveshah: yup, it works fine now !
<daveshah>
awesome
<sxpert>
ZipCPU: it's a module of a more grandiose thing
* ZipCPU
envisions taj-mahols (or however those things are spelled ...)
<sxpert>
starting with the little things, and going to the more complicated things later
<sxpert>
but it needs things like a bitmask generator
<sxpert>
and shifters
<ZipCPU>
Is your FPGA a companion chip to a bigger/greater processor/controller?
<sxpert>
nope, everything will be in there
<ZipCPU>
... without a clock??
<sxpert>
clock comes later
<ZipCPU>
Why later? I find I need to start with the clock, lest my designs get too slow
<sxpert>
well testing combinatorial logic modules at this point, will do the state machine later
<ZipCPU>
Do you expect to have much of a state machine? Different CPUs have different needs/designs, but I'd be curious about yours
<sxpert>
not much info on the real hardware, hardware wise, designing to the arch docs
<tnt>
Oh, that's the CPU in my HP48 IIRC.
<sxpert>
yeah
<ZipCPU>
I love watching individuals take past CPUs and cloning them on FPGAs. I'm still somewhat shocked that the Cray of my parents generation now fits on an FPGA.
* ZipCPU
reminisces fondly of the old Cray computers
<sxpert>
some dude built a model of a cray around his devboard
<ZipCPU>
Yep! and it still blows me away
<sxpert>
in fact I'm looking into buidling a giant HP48 with a giant led screen
<tnt>
sxpert: btw, I looked at lcc which was referenced from the website you pointed to earlier. Looks interesting. As usual the biggest problem is that most compilers deal badly with a pure 16 bit process (i.e. no native byte support and all address are word addresses).
<tnt>
sxpert: Oh, that would be awesome !
<sxpert>
maybe using some 32*32 panels or something
<sxpert>
could use the pixels on the side for the indicators, instead of having them on top
<tnt>
sxpert: two 64x64 panels would do. (you'd be missing 2 pixel width but I guess it's fine :p)
<sxpert>
; if I do 9x16 on the width, I have space to display the indicators
<sxpert>
I can easily do 8x8 indicators
<sxpert>
I can also do 64x160 and have yet more space
<sxpert>
that's a long time away though
massi_ has joined ##openfpga
ayjay_t_ has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
<gruetzkopf>
i really like the early crays with their differential wirewrap ratsnest
<gruetzkopf>
i've only gotten to like 2 racks of wirewrap until now
ayjay_t_ has quit [Read error: Connection reset by peer]
<azonenberg>
apparently MCHP has a "product we have scheduled for release in July of this year" that's a successor to the ksz9031
<azonenberg>
unsure if it will be called the KSZ9041 or something else
massi_ has quit [Remote host closed the connection]
<sxpert>
microchip ethernet phy ?
<gruetzkopf>
oh, interesting
<azonenberg>
i had inquired about adding a pll lock status register to the next die spin
<azonenberg>
they said they had a new part coming out in july, he checked the docs, and there was no such register
<tnt>
there is always the next one :)
<azonenberg>
lol
<azonenberg>
well i hope to not have this problem again
<azonenberg>
now that i know to avoid mems oscs like the plague when this chip is involved
<tnt>
that chip does seem to requires pretty low jitter. I mean 200 ps on a 25 MHz clock isn't great but it's also not all that horrible.
<azonenberg>
it requires 100ps
<azonenberg>
i was giving it 180 or so
<azonenberg>
100ps is 0.0025 UI of jitter
<tnt>
yeah, I know. (ok, I rounded 180 to 200 ...)
<azonenberg>
that's incredibly low
<whitequark>
wtf
<whitequark>
why is it so sensitive?
<azonenberg>
The jitter on the mems osc wont even show up on my 4 Gsps scope
<azonenberg>
(250 ps per sample)
<azonenberg>
I have a 350 MHz scope and it can't see the problem with my 25 MHz clock
<azonenberg>
whitequark: i... wish i knew
<azonenberg>
it must just be a really sucky PLL
<azonenberg>
the chip works fine when you give it a good clock, and it's inexpensive enough that you're still better off using it plus a nice crystal than a fancy marvell/broadcom phy and a cheaper osc
<azonenberg>
(and the no-NDA datasheet is a big point in its favor)
<tnt>
interesting that the jitter spec is one of the revision of the datasheet ( DS00002117B added it )
<daveshah>
Makes sense, I doubt they would design it with such a requirement from the beginning
<sxpert>
azonenberg: well, you want to avoid mems oscs in anycase, for instance, if your device is to be used close to an MRI machine ;)
<sxpert>
like, say, an iPhone ;)
<azonenberg>
tnt: yes i know
<azonenberg>
somebody else found out the hard way
<azonenberg>
After i had done a design using a random quartz osc, figured i was fine
<azonenberg>
next board used a mems since i didnt remember any odd clock requirements
<azonenberg>
:p
<azonenberg>
sxpert: being around an MRI isnt the problem
<azonenberg>
Being around a freshly installed MRI that vented lots of helium while being chilled? Thats another story
<sxpert>
except when there's an He leak of some sort
<azonenberg>
yeah thats what i mean though
<azonenberg>
when operating normally the mri isnt the issue
<sxpert>
you may get that metal case stuck to the magnet though ;)
<azonenberg>
Details details
<azonenberg>
Lol
<sxpert>
or that floor scrubbing machine ;)
<davidc__>
azonenberg: back when they were Micrel, I did a board using their reference design (was a proof-of-concept prototype, so I wasn't too concerned about engineering the heck out of it)
<davidc__>
azonenberg: it was for one of their GIGE phys
<azonenberg>
and?
<davidc__>
azonenberg: and it had a Vcore regulator that was built using an external pass MOSFET
<azonenberg>
Yeah same one, probably the ksz9021
<davidc__>
Their reference design used a Micrel FET, of course
<azonenberg>
I've always used an external smps to feed 1v2 directly
<sxpert>
obviously
<davidc__>
So, I just plunked down their reference design, and assumed all would be good
<azonenberg>
and not used the integrated ldo
<sxpert>
davidc__: nope ;)
<davidc__>
sxpert: the FET dissipated so much power, and was so grossly undersized, that it desoldered itself from the board
<azonenberg>
looool
<azonenberg>
wut
<azonenberg>
(remind me not to use that ldo ever)
<davidc__>
well, the LDO was fine... with a decent FET
<sxpert>
davidc__: reminds me of Apple II disk drives, that needed to be setup on their back, otherwise, motor H-bridge would fall to the bottom of the box
<davidc__>
azonenberg: this was a tiny SC70-6 part, with nowhere near the power sinking capability
<azonenberg>
LOL
<davidc__>
azonenberg: something I would have noticed had I thought about it; but this was a frantic rush to get the board out the door to demo working HW for an investor meeting
<davidc__>
And the hardware did work eventually; I just ran a line from the FPGA 1V2 supply I already had on the board, and all was well
<sxpert>
the important thing... did it work long enough to get the dude to sign the contract ?)
<davidc__>
hah, the startup failed for lack of funding, but it did work for the meeting!
<whitequark>
lol
<sxpert>
heh lol
<davidc__>
(It was a firewalling application; I had GIGE line rate packet classification, 4 flows in total, working in an XC3S500E..... I have permission to open source that code; I should do that some day)
<sxpert>
\o
<davidc__>
It had a little custom classifier CPU core that ran at 150Mhz (which was .. difficult... in the S3E days). key parts were written with raw S3E primitives all RLOCed to actually hit timing. So... essentially useless in anything else :)