|
hobbesmaster posted:well if you want to take a lot of breaks while its i used to have 2 hour builds, I'd be lucky to get five builds a day. lots of multi-tasking
|
#
¿
Feb 24, 2015 01:53
|
|
|
|
| # ¿ May 15, 2024 16:59 |
|
|
Bloody posted:when does the other shoe drop? fs, sf and temperature. ff/ss if you're unlucky
|
|
#
¿
Feb 25, 2015 08:16
|
|
|
Bloody posted:it isnt happening this morning lol timing
|
|
#
¿
Mar 19, 2015 07:13
|
|
|
i've just finished getting our custom jtag subsystem working (since we love doing things the hard way), because we want to be able program/debug msp430s and various other poo poo in-system -- so much hdl, now i can move on to real work like all the hardware that's like a month behind schedule incidentally the ft2232h is a pretty neat chip -- anyone using the bus blaster w/ adaptive clocking and urjtag?
|
|
#
¿
Mar 19, 2015 07:14
|
|
|
kwinkles posted:i2c ultra fast mode can do 5Mb/s, oooh yeaaaaaah, i did pre-silicon verification of the i2c and displayport aux channel controller in bay trail and i used to have dreams about i2c i spent so much time fiddling with it in the day for a few weeks there i have sometimes woken up in bed and laid there unmoving for several minutes before realizing that i do not, in fact, require a clock signal to function properly
|
|
#
¿
Apr 3, 2015 19:21
|
|
|
Star War Sex Parrot posted:dude get on my level not an arduino, ++ points
|
|
#
¿
Apr 3, 2015 19:24
|
|
|
Mr Dog posted:spi is "anything with at least one shift register that connects to the outside world and maybe a select line", yes let me tell you about the shift register known as jtag jtag owns bones.
|
|
#
¿
Apr 3, 2015 19:25
|
|
|
Mido posted:rec ft2232 based things are decent and inexpensive, if used with a non-lovely userspace application not sure how they do with adaptive clocking tho
|
|
#
¿
Apr 3, 2015 21:37
|
|
|
Mido posted:is adaptive clocking up to the host doing the debugging? or the processor/soc/debugging architecture you're interacting with? iiuc it's up to the debugger -- it will wait for the first tdo bit to come back before the next clock edge thus compensating for any cable delay or synchronizer flop delays (useful when you're trying to debug an arm target that comes up at say 32khz and then jumps up in speed to 50mhz+)
|
|
#
¿
Apr 4, 2015 02:57
|
|
|
Arcsech posted:Agreed on Vivado vivado / xilinx still doesn't understand the concept of people wanting to version control stuff though. why the gently caress do i have to hand-write my own tcl scripts to run the entire build flow because you fucks are unwilling to jump into the 21st century and embrace source control 
|
|
#
¿
Apr 6, 2015 00:39
|
|
|
JawnV6 posted:i've been using source control outside my IDE for a while now. the IDE's up on one screen and the terminal's on the other, is even that unsupported or do you want some hint of modernness like "commit hooks" or w/e? so in a vivado zynq design, you can do a block design to easily stitch together axi peripherals and stuff this is fine, and i would expect that i should be version control the two text files that control and spawn the auto-generation of hdl from them but no, oh loving now. every. goddamned. time. you build, it happily increments a number and renames the core. so, *_design_auto_pc_1 eventually becomes *_design_auto_pc_161 and it's a bunch of utterly loving useless commits. they're a bunch of cocksuckers, unless it's been secretly fixed in the background i'm this close to just cribbing off what adi did for their hdl libraries
|
|
#
¿
Apr 7, 2015 18:35
|
|
|
don't even get me started on trying to version control the shitshow that's version controlling the export process over to their sdk tool as well (an eclipse-based system) at least eclipse has some user community that's figured out ways to deal with that special brand of bullshit
|
|
#
¿
Apr 7, 2015 18:37
|
|
|
JawnV6 posted:i live in sf and/or "no" how do you feel about seattle? BobHoward posted:what did adi do for their hdl libs basically exactly what you described and what i haven't had the time to do; maybe i'll just have to sit down one weekend and burn that on transferring my project over to a purely tcl-driven flow. it only took me a day or two to do that for the microsemi stuff, which wasn't too bad.
|
|
#
¿
Apr 16, 2015 06:17
|
|
|
ncvlog is the Verilog compiler from Cadence Incisive Simulator -- mega loving bucks. used it heavily for a good 4 years before switching to QuestaSim, at one point I tracked down the original firm that they assimilated into there, but don't remember what it is -- that's where the nc- prefix for all the tools comes from.
|
|
#
¿
May 7, 2015 23:17
|
|
|
JawnV6 posted:async clock crossing is sweet, one of those concepts that took 1.5 passes for me to understand tell me more about the clock crossing
|
|
#
¿
Jun 15, 2015 00:40
|
|
|
Bloody posted:hey fellow bit janitors, im looking for a bluetooth soc that has a dac, any suggestions? it seems to be a surprisingly hard combo to find. anything from nordic?
|
|
#
¿
Jun 16, 2015 00:29
|
|
|
hey so if i want asserts in verilog-2001 -- what do?
|
|
#
¿
Jun 22, 2015 07:39
|
|
|
JawnV6 posted:do you need a little structure around $display calls or do you have the flexibility to pull in something like OVM mostly i've got some simple parameterized modules where i want to barf if the idiot user tries to make width 0 registers or similar things ovm sounds like something that'd be cool to start using though -- our stuff is so simple right now / so tiny (igloo nano fpgas) that it's not required, but i want to learn more about it
|
|
#
¿
Jun 22, 2015 08:22
|
|
|
JawnV6 posted:yeah this is huge, having something that windows can poke at over PCIe that costs under $1k instead of starting driver development after a few million in fab costs its even cheaper, the low-end kits from altera and xilinx with the low-end fabric + pcie hard ip + transceivers are around $500 or so i think it takes like 20 minutes to go from out-of-box to running some custom logic to make leds blink using 5 GT/s pcie, pretty legit
|
|
#
¿
Jun 30, 2015 07:38
|
|
|
vivado 2015.2 out today someone please go suffer and report back how much it sucks.
|
|
#
¿
Jul 1, 2015 21:02
|
|
|
Arcsech posted:i dont know much about the specifics of what youre talking about but every xilinx software tool ive ever used has been a giant piece of poo poo so theyre probably really bad also this
|
|
#
¿
Jul 1, 2015 21:02
|
|
|
Mr Dog posted:the worst is everything produced by microchip whoa buddy let's not say things that we can't take back
|
|
#
¿
Jul 24, 2015 22:14
|
|
|
too many tiny nanoseconds
|
|
#
¿
Jul 26, 2015 08:44
|
|
|
i got number 3 down
|
|
#
¿
Jul 30, 2015 17:08
|
|
|
BobHoward posted:if you want to go brand x, i recommend the avnet microzed for $200 plus an io breakout board for $50. it's a zynq part so it's actually an arm soc with some 7 series fpga fabric on the side, which is a very nice combo. boots linux from a microsd card out of the box, 1gb ram, gigabit enet, dual core cortex-a9 so it's reasonable fast, and loading a bitfile into the fpga fabric is literally "cat yospos.bit >/dev/some/path/i/dont/remember" hmm is that devcfg driver in xilinx mainline? remember what its called?
|
|
#
¿
Aug 6, 2015 17:46
|
|
|
Mr Dog posted:100K is a bit much for I2C pullups, isn't it? yes and lol
|
|
#
¿
Oct 12, 2015 16:44
|
|
|
i'm itching to do something with a fpga and it's been awhile since i've console nerded out tell me about optical drive pickup assemblies
|
|
#
¿
Dec 10, 2015 21:11
|
|
|
JawnV6 posted:wrong answer oh god i figure a zynq would be perfect for that though.
|
|
#
¿
Dec 10, 2015 21:16
|
|
|
i posted awhile back in the retro games thread about wanting to roll my own ps2 modchip for shits and giggles (and to figure out how they did it back in the day) now i was recently thinking that if i could replace the optical pickup assembly in any given optical drive with a solid-state version, you can boot anything you want on the real hardware regardless of health of the wear item (laser) i figure this will interest approximately 7.32 people so they can play their ps2 jrpgs until the end of time
|
|
#
¿
Dec 10, 2015 21:18
|
|
|
JawnV6 posted:oh doing THAT end of it oh yeah, no -- that's what a couple of things do right now, but there's always that slight weirdness for one title or another (that comes from emulating a reverse-engineered interface) i think the dreamcast was more or less atapi, but the ps1/ps2 in very japanese fashion have some hilarious large (probably like... .25um or larger) discrete asics that implement the drive controller (mechacon). studying the schematics i've found and the modchip install points, it looks like most chips hop onto some of the bios mask rom address/data lines, a couple of cs / oe lines and then a couple of pins on the mechacon however, if you build something with a dac that emulates the signals a laser would normally transmit, then no one will ever be the wiser (i think) -- you take in the motor control and turn that into your clock, trigger e/f to have 'perfect focus', and then a/b/c/d as the data, but i can't find any good documentation on this poo poo.
|
|
#
¿
Dec 10, 2015 21:30
|
|
|
JawnV6 posted:hold the phone... this sorta implies you've found good documentation on other poo poo??? where?? the schematic pdfs i have for the ps2 and ps1 are actually pretty loving amazing -- i don't know what cad package puts it out, or if it is a technical writing group but man it's hot
|
|
#
¿
Dec 10, 2015 22:27
|
|
|
peep it: i have the full pdf too, pm if you want it
|
|
#
¿
Dec 12, 2015 03:31
|
|
|
i think IC801 is a TI op-amp but i'm not sure. it's the first stage interface to the optical drive, and then it goes further to ic605 which is a sony cxd1869aq asic (cd/dvd dsp) coupled with cxp101064, another asic which is on mechacon duty. (aside, i wonder if there's a list of sony part prefixes somewhere). the dsp does the real nasty work of reading from discs. the injection point is CN801. from what i have been able to find on how cd/dvd drives fuckin' work (greybeard heaven: http://www.repairfaq.org/REPAIR/F_cdfaq9.html#CDFAQ_009) A, B, C, D -- focus / data signals E, F -- tracking (potentially stupid simple to emulate since i will have perfect tracking / focus) PD1, PD2 -- photodiode 1, photodiode 2 (laser diode?) ABCD appear to be ac coupled cn804 is the spindle motor connector, which i think i only need to use as an input to get an idea of where the host wants the target disc H/H1/H2/H3/A1/A2/A3 -- drive motors and poo poo i need to find a datasheet on IC801 but it is tough. ic802 is Rohm i think judging from the part number prefix (and the japanese love rohm). PD1/PD2/A-F I think are the set of high-bandwidth signals to generate into the RF amp, and then the 'control bus' is my input as to what it's asking for. and can i reiterate again how loving nice these schematics are? absolutely miserable to print out i'm sure but beautiful on a screen e: 
movax fucked around with this message at 03:43 on Dec 12, 2015 |
|
#
¿
Dec 12, 2015 03:37
|
|
|
as a comparison, the ps1 uses the super common ksm-440aem opa: different rf amp this time (that was probably in a fuckload of sony cd players), but slightly less signals since it's a CD only still 2 PD signals, and only E and F out now. no A, B, C or D. spindle motor / sled motor is a separate connector i'm like 15 years too late to this -- i tried searching TIs/etc websites for their marketing poo poo intended for optical drive makers in the 90s and i can't find it anywhere. bet they'd have reference designs that would be more than happy to show how to use their parts to build this. Barnyard Protein posted:yeah thats a nice schematic, what is it done in? zuken? could be, i've heard good things about zuken.
|
|
#
¿
Dec 12, 2015 03:48
|
|
|
now that i'm kind of revisiting this project (http://www.repairfaq.org/REPAIR/F_cdfaq1.html#CDFAQ_012) (editor note: this poo poo is complex and economies of scale always blow my mind -- these things became loving ubiquitous) using the ps1 rf amp as a reference -- * LD is laser diode output that uses Q701 and friends to power the actual laser diode inside the opa * the PD pins are sense inputs, for what i'm not sure -- closed loop control of laser power, most likely. *the actual reading element is essentially a quadrant detector i'm pretty sure -- the document says that focus is perfect when (A+C)-(B+D) = 0. i guess the ps1 may not be a 3-beam pickup system. E and F must be the only data coming out of the drive. found a datasheet for the CXA2586 which is a photodiode ic for cd-rom / dvd-rom drives and it basically confirms that each photodiode output is a high-speed iv amplifier -- converts photocurrent to a voltage. runs off the supply rail of said pdic as well. i think my block-diagram would be something like: data store -> buffer -> FPGA -> serial DAC -> AFE -> connector fpga handles taking raw iso data and applies efm to generate the appropriate signaling data store being a SD card (probably), or if i use a zynq or something (oh god $$$), it could be anything and i dma it into fabric from ethernet/sd/usb/sata/what have you e:  really need to get the datasheet(s) of the CXA2575N and SP3727ACA. movax fucked around with this message at 04:25 on Dec 12, 2015 |
|
#
¿
Dec 12, 2015 04:04
|
|
|
eschaton posted:so there's no tap where you can just inject a bitstream? there is a tap where i could inject a bitstream; there's always the option of moving in layers and emulating different aspects of the interface, but there's some additional complexity there and additional risk of introducing weird one-off glitches because there's some game out there that expects certain timing behavior BobHoward posted:how are you going to handle seeking, optical drives have some interesting stuff going on there which requires some kind of feedback in the data stream the way i understand it, there's only a couple of possible inputs to the drive to set position / read speed stuff, and that's the spindle motor speed, the tray position (sliding) and a tilt angle. it looks like most of the amplifiers output tracking error and focus error signals too; if i can simulate zero tracking error and focus error, that might work -- but then again, some error might be expected because it (the actual dsp / controller) uses it as a control loop to figure out where on the disc it is vs. where it needs to be.
|
|
#
¿
Dec 12, 2015 19:34
|
|
|
BobHoward posted:the control loop during a seek is what i was thinking of, iirc the drive tries to make an estimated seek movement, looks at the sector #, then makes a correction (which might be in the opposite direction), looks again, repeats until it hits a sector before and sufficiently close to the target sector of the seek, and then waits for it to arrive in the data stream i just ordered a copy of 'dvd players and drives' from amazon for like $5 -- the google preview had some pretty good indications that the dude goes in depth about the details of the focus searching / tracking error stuff. i think i detailed the pinout of the ps2 dvd-rom to myself in sufficient fashion as well: code:i think in the end it all gets turned into the rf output which is all 1s and 0s (in both ac coupled and dc coupled form); i could maybe jump in there, but then soldering begins to be required instead of simple harnessing so the input seeking commands i believe would be based on the tracking coil, focus coil, and sled movement (on a different connector) inputs, all of which are fed to the ba5815fm driver ic. i can probably put a small dummy coil load in place, feed that into an adc and use that in the digital domain to see what the drive controller thinks he's requesting. for outputting simulated photodiode signals, the best option might actually be putting dummy diodes and outputting across them with a dac to generate the expected voltages. the PDIC inside the opa acts as a IV amplifier so maybe feeding an op-amp or diodes with a digital waveform may take care of my analog interface problems. i'm only semi-concerned about the power-budget -- there's a 5V connection on the PS2, but i have no idea how much current it could source. i'd really love to make ethernet an option for this, but sd card is sadly probably the simplest method. with ethernet i'd have to deal with embedded tcp/ip stacks, and i'm cringing thinking of implementing stable smb/cifs/nfs support, unless i use something that can run linux, and now i need ddr and it's going to miserable and lovely. maybe a wifi module + bluetooth serial modem (for config via phone app) is the most user-friendly way of streaming content to this thing, in conjunction with a local sd slot 'just in case'. e: the best part is i finally have a project to work on in the past few years that doesn't need to be concerned about radiation tolerance at all -- so every part is an option, hooray! movax fucked around with this message at 22:23 on Dec 12, 2015 |
|
#
¿
Dec 12, 2015 22:11
|
|
|
Spatial posted:cool, i didn't know these kinds of docs were out there im pretty sure it's for tilting the optical drive sled / lens to improve focus and tracking accuracy, but not 100% sure
|
|
#
¿
Dec 13, 2015 01:47
|
|
|
Bloody posted:im thinkin about sticking a cpu core in my fpga because sending variable length strings over uart from verilog sounds like a horrendous pain in the rear end softcore cpus are fun Barnyard Protein posted:agreed i wouldnt feel bad, thinking about it, this is at heart a high-speed photodiode simulator. that honestly sounds boring as gently caress -- i need a cool project name, how can i start writing code or making project files / git repos if i don't have a project name!
|
|
#
¿
Dec 14, 2015 21:52
|
|
|
|
| # ¿ May 15, 2024 16:59 |
|
|
did you forget ground return wires so you needed a certain number of '0' in the data lines to act as a ground return? parallel interfaces only, obv.
|
|
#
¿
Dec 15, 2015 02:27
|
|